hlrs-software-stack/spack
7
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #1327 from suraia/update-load-documentation

Browse source 
Update documentation for recursive module loading
This commit is contained in:
Todd Gamblin 2016-07-21 08:33:40 -07:00 committed by GitHub
commit 0b1d03abe6
1 changed files with 31 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

61
lib/spack/docs/basic_usage.rst
View file

@ -546,7 +546,7 @@ More formally, a spec consists of the following pieces:
boolean variants boolean variants
* ``name=<value>`` Optional compiler flag specifiers. Valid flag names are * ``name=<value>`` Optional compiler flag specifiers. Valid flag names are
``cflags``, ``cxxflags``, ``fflags``, ``cppflags``, ``ldflags``, and ``ldlibs``. ``cflags``, ``cxxflags``, ``fflags``, ``cppflags``, ``ldflags``, and ``ldlibs``.
* ``target=<value> os=<value>`` Optional architecture specifier * ``target=<value> os=<value>`` Optional architecture specifier
(``target=haswell os=CNL10``) (``target=haswell os=CNL10``)
* ``^`` Dependency specs (``^callpath@1.1``) * ``^`` Dependency specs (``^callpath@1.1``)
@ -764,12 +764,12 @@ words ``target`` and/or ``os`` (``target=x86-64 os=debian7``). You can also
use the triplet form of platform, operating system and processor. use the triplet form of platform, operating system and processor.
.. code-block:: sh .. code-block:: sh
spack install libelf arch=cray_xc-CNL10-haswell spack install libelf arch=cray_xc-CNL10-haswell
Users on non-Cray systems won't have to worry about specifying the architecture. Users on non-Cray systems won't have to worry about specifying the architecture.
Spack will autodetect what kind of operating system is on your machine as well Spack will autodetect what kind of operating system is on your machine as well
as the processor. For more information on how the architecture can be as the processor. For more information on how the architecture can be
used on Cray machines, check here :ref:`spack-cray` used on Cray machines, check here :ref:`spack-cray`
@ -1147,11 +1147,12 @@ packages use RPATH to find their dependencies: this can be true in
particular for Python extensions, which are currently *not* built with particular for Python extensions, which are currently *not* built with
RPATH. RPATH.
Modules may be loaded recursively with the command: Modules may be loaded recursively with the ``load`` command's
``--dependencies`` or ``-r`` argument:
.. code-block:: sh .. code-block:: sh
$ module load `spack module tcl --dependencies <spec>... $ spack load --dependencies <spec> ...
More than one spec may be placed on the command line here. More than one spec may be placed on the command line here.
@ -1793,36 +1794,36 @@ A nicer error message is TBD in future versions of Spack.
Spack on Cray Spack on Cray
----------------------------- -----------------------------
Spack differs slightly when used on a Cray system. The architecture spec Spack differs slightly when used on a Cray system. The architecture spec
can differentiate between the front-end and back-end processor and operating system. can differentiate between the front-end and back-end processor and operating system.
For example, on Edison at NERSC, the back-end target processor For example, on Edison at NERSC, the back-end target processor
is \"Ivy Bridge\", so you can specify to use the back-end this way: is \"Ivy Bridge\", so you can specify to use the back-end this way:
.. code-block:: sh .. code-block:: sh
spack install zlib target=ivybridge spack install zlib target=ivybridge
You can also use the operating system to build against the back-end: You can also use the operating system to build against the back-end:
.. code-block:: sh .. code-block:: sh
spack install zlib os=CNL10 spack install zlib os=CNL10
Notice that the name includes both the operating system name and the major Notice that the name includes both the operating system name and the major
version number concatenated together. version number concatenated together.
Alternatively, if you want to build something for the front-end, Alternatively, if you want to build something for the front-end,
you can specify the front-end target processor. The processor for a login node you can specify the front-end target processor. The processor for a login node
on Edison is \"Sandy bridge\" so we specify on the command line like so: on Edison is \"Sandy bridge\" so we specify on the command line like so:
.. code-block:: sh .. code-block:: sh
spack install zlib target=sandybridge spack install zlib target=sandybridge
And the front-end operating system is: And the front-end operating system is:
.. code-block:: sh .. code-block:: sh
spack install zlib os=SuSE11 spack install zlib os=SuSE11
@ -1830,13 +1831,13 @@ And the front-end operating system is:
Cray compiler detection Cray compiler detection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Spack can detect compilers using two methods. For the front-end, we treat Spack can detect compilers using two methods. For the front-end, we treat
everything the same. The difference lies in back-end compiler detection. everything the same. The difference lies in back-end compiler detection.
Back-end compiler detection is made via the Tcl module avail command. Back-end compiler detection is made via the Tcl module avail command.
Once it detects the compiler it writes the appropriate PrgEnv and compiler Once it detects the compiler it writes the appropriate PrgEnv and compiler
module name to compilers.yaml and sets the paths to each compiler with Cray\'s module name to compilers.yaml and sets the paths to each compiler with Cray\'s
compiler wrapper names (i.e. cc, CC, ftn). During build time, Spack will load compiler wrapper names (i.e. cc, CC, ftn). During build time, Spack will load
the correct PrgEnv and compiler module and will call appropriate wrapper. the correct PrgEnv and compiler module and will call appropriate wrapper.
The compilers.yaml config file will also differ. There is a The compilers.yaml config file will also differ. There is a
modules section that is filled with the compiler\'s Programming Environment modules section that is filled with the compiler\'s Programming Environment
@ -1849,8 +1850,8 @@ and module name. On other systems, this field is empty []::
- intel/15.0.109 - intel/15.0.109
... ...
As mentioned earlier, the compiler paths will look different on a Cray system. As mentioned earlier, the compiler paths will look different on a Cray system.
Since most compilers are invoked using cc, CC and ftn, the paths for each Since most compilers are invoked using cc, CC and ftn, the paths for each
compiler are replaced with their respective Cray compiler wrapper names:: compiler are replaced with their respective Cray compiler wrapper names::
... ...
@ -1862,7 +1863,7 @@ compiler are replaced with their respective Cray compiler wrapper names::
... ...
As opposed to an explicit path to the compiler executable. This allows Spack As opposed to an explicit path to the compiler executable. This allows Spack
to call the Cray compiler wrappers during build time. to call the Cray compiler wrappers during build time.
For more on compiler configuration, check out :ref:`compiler-config`. For more on compiler configuration, check out :ref:`compiler-config`.
@ -1889,11 +1890,11 @@ Here\'s an example of an external configuration for cray modules:
This tells Spack that for whatever package that depends on mpi, load the This tells Spack that for whatever package that depends on mpi, load the
cray-mpich module into the environment. You can then be able to use whatever cray-mpich module into the environment. You can then be able to use whatever
environment variables, libraries, etc, that are brought into the environment environment variables, libraries, etc, that are brought into the environment
via module load. via module load.
You can set the default compiler that Spack can use for each compiler type. You can set the default compiler that Spack can use for each compiler type.
If you want to use the Cray defaults, then set them under *all:* in packages.yaml. If you want to use the Cray defaults, then set them under *all:* in packages.yaml.
In the compiler field, set the compiler specs in your order of preference. In the compiler field, set the compiler specs in your order of preference.
Whenever you build with that compiler type, Spack will concretize to that version. Whenever you build with that compiler type, Spack will concretize to that version.
Here is an example of a full packages.yaml used at NERSC Here is an example of a full packages.yaml used at NERSC
@ -1921,11 +1922,11 @@ Here is an example of a full packages.yaml used at NERSC
Here we tell spack that whenever we want to build with gcc use version 5.2.0 or Here we tell spack that whenever we want to build with gcc use version 5.2.0 or
if we want to build with intel compilers, use version 16.0.0.109. We add a spec if we want to build with intel compilers, use version 16.0.0.109. We add a spec
for each compiler type for each cray modules. This ensures that for each for each compiler type for each cray modules. This ensures that for each
compiler on our system we can use that external module. compiler on our system we can use that external module.
For more on external packages check out the section :ref:`sec-external_packages`. For more on external packages check out the section :ref:`sec-external_packages`.
Getting Help Getting Help
----------------------- -----------------------