178 lines
6.9 KiB
ReStructuredText
178 lines
6.9 KiB
ReStructuredText
.. _site-configuration:
|
|
|
|
Site configuration
|
|
===================================
|
|
|
|
.. _temp-space:
|
|
|
|
Temporary space
|
|
----------------------------
|
|
|
|
.. warning:: Temporary space configuration will eventually be moved to
|
|
configuration files, but currently these settings are in
|
|
``lib/spack/spack/__init__.py``
|
|
|
|
By default, Spack will try to do all of its building in temporary
|
|
space. There are two main reasons for this. First, Spack is designed
|
|
to run out of a user's home directory, and on may systems the home
|
|
directory is network mounted and potentially not a very fast
|
|
filesystem. We create build stages in a temporary directory to avoid
|
|
this. Second, many systems impose quotas on home directories, and
|
|
``/tmp`` or similar directories often have more available space. This
|
|
helps conserve space for installations in users' home directories.
|
|
|
|
You can customize temporary directories by editing
|
|
``lib/spack/spack/__init__.py``. Specifically, find this part of the file:
|
|
|
|
.. code-block:: python
|
|
|
|
# Whether to build in tmp space or directly in the stage_path.
|
|
# If this is true, then spack will make stage directories in
|
|
# a tmp filesystem, and it will symlink them into stage_path.
|
|
use_tmp_stage = True
|
|
|
|
# Locations to use for staging and building, in order of preference
|
|
# Use a %u to add a username to the stage paths here, in case this
|
|
# is a shared filesystem. Spack will use the first of these paths
|
|
# that it can create.
|
|
tmp_dirs = ['/nfs/tmp2/%u/spack-stage',
|
|
'/var/tmp/%u/spack-stage',
|
|
'/tmp/%u/spack-stage']
|
|
|
|
The ``use_tmp_stage`` variable controls whether Spack builds
|
|
**directly** inside the ``var/spack/`` directory. Normally, Spack
|
|
will try to find a temporary directory for a build, then it *symlinks*
|
|
that temporary directory into ``var/spack/`` so that you can keep
|
|
track of what temporary directories Spack is using.
|
|
|
|
The ``tmp_dirs`` variable is a list of paths Spack should search when
|
|
trying to find a temporary directory. They can optionally contain a
|
|
``%u``, which will substitute the current user's name into the path.
|
|
The list is searched in order, and Spack will create a temporary stage
|
|
in the first directory it finds to which it has write access. Add
|
|
more elements to the list to indicate where your own site's temporary
|
|
directory is.
|
|
|
|
|
|
External Packages
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
It's possible for Spack to use certain externally-installed
|
|
packages rather than always rebuilding packages. This may be desirable
|
|
if machines ship with system packages, such as a customized MPI
|
|
that should be used instead of Spack building its own MPI.
|
|
|
|
External packages are configured through the ``packages.yaml`` file found
|
|
in a Spack installation's ``etc/spack/`` or a user's ``~/.spack/``
|
|
directory. Here's an example of an external configuration::
|
|
|
|
.. code-block:: yaml
|
|
|
|
packages:
|
|
- openmpi@1.4.3%gcc@4.4.7=chaos_5_x86_64_ib:
|
|
path: /opt/openmpi-1.4.3
|
|
- openmpi@1.4.3%gcc@4.4.7=chaos_5_x86_64_ib+debug:
|
|
path: /opt/openmpi-1.4.3-debug
|
|
- openmpi@1.6.5%intel@10.1=chaos_5_x86_64_ib:
|
|
path: /opt/openmpi-1.6.5-intel
|
|
|
|
This example lists three installations of OpenMPI, one built with gcc,
|
|
one built with gcc and debug information, and another built with OpenMPI.
|
|
If Spack is asked to build a package that uses one of these MPIs as a
|
|
dependency, it link the package to the pre-installed OpenMPI in
|
|
the given directory.
|
|
|
|
Each ``packages.yaml`` should begin with a ``packages:`` token, followed
|
|
by a list of package specs. Specs in the ``packages.yaml`` have at most
|
|
one ``path`` tag, which specifies the top-level directory where the
|
|
spec is installed.
|
|
|
|
Each spec should be as well-defined as reasonably possible. If a
|
|
package lacks a spec component, such as missing a compiler or
|
|
package version, then Spack will guess the missing component based
|
|
on its most-favored packages, and it may guess incorrectly.
|
|
|
|
All package versions and compilers listed in ``packages.yaml`` should
|
|
have entries in Spack's packages and compiler configuration, even
|
|
the package and compiler may not actually be used.
|
|
|
|
The packages configuration can tell Spack to use an external location
|
|
for certain package versions, but it does not restrict Spack to using
|
|
external packages. In the above example, if an OpenMPI 1.8.4 became
|
|
available Spack may choose to start building and linking with that version
|
|
rather than continue using the pre-installed OpenMPI versions.
|
|
|
|
To prevent this, the ``packages.yaml`` configuration also allows packages
|
|
to be flagged as non-buildable. The previous example could be modified to
|
|
be::
|
|
|
|
.. code-block:: yaml
|
|
|
|
packages:
|
|
- openmpi:
|
|
nobuild: True
|
|
- openmpi@1.4.3%gcc@4.4.7=chaos_5_x86_64_ib:
|
|
path: /opt/openmpi-1.4.3
|
|
- openmpi@1.4.3%gcc@4.4.7=chaos_5_x86_64_ib+debug:
|
|
path: /opt/openmpi-1.4.3-debug
|
|
- openmpi@1.6.5%intel@10.1=chaos_5_x86_64_ib:
|
|
path: /opt/openmpi-1.6.5-intel
|
|
|
|
The addition of the ``nobuild`` flag tells Spack that it should never build
|
|
its own version of OpenMPI, and it will instead always rely on a pre-built
|
|
OpenMPI. Similar to ``path``, ``nobuild`` is specified as a property under
|
|
a spec and will prevent building of anything that satisfies that spec.
|
|
|
|
The ``nobuild`` does not need to be paired with external packages.
|
|
It could also be used alone to forbid versions of packages that may be
|
|
buggy or otherwise undesirable.
|
|
|
|
|
|
Profiling
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Spack has some limited built-in support for profiling, and can report
|
|
statistics using standard Python timing tools. To use this feature,
|
|
supply ``-p`` to Spack on the command line, before any subcommands.
|
|
|
|
.. _spack-p:
|
|
|
|
``spack -p``
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
``spack -p`` output looks like this:
|
|
|
|
.. code-block:: sh
|
|
|
|
$ spack -p graph dyninst
|
|
o dyninst
|
|
|\
|
|
| |\
|
|
| o | libdwarf
|
|
|/ /
|
|
o | libelf
|
|
/
|
|
o boost
|
|
|
|
307670 function calls (305943 primitive calls) in 0.127 seconds
|
|
|
|
Ordered by: internal time
|
|
|
|
ncalls tottime percall cumtime percall filename:lineno(function)
|
|
853 0.021 0.000 0.066 0.000 inspect.py:472(getmodule)
|
|
51197 0.011 0.000 0.018 0.000 inspect.py:51(ismodule)
|
|
73961 0.010 0.000 0.010 0.000 {isinstance}
|
|
1762 0.006 0.000 0.053 0.000 inspect.py:440(getsourcefile)
|
|
32075 0.006 0.000 0.006 0.000 {hasattr}
|
|
1760 0.004 0.000 0.004 0.000 {posix.stat}
|
|
2240 0.004 0.000 0.004 0.000 {posix.lstat}
|
|
2602 0.004 0.000 0.011 0.000 inspect.py:398(getfile)
|
|
771 0.004 0.000 0.077 0.000 inspect.py:518(findsource)
|
|
2656 0.004 0.000 0.004 0.000 {method 'match' of '_sre.SRE_Pattern' objects}
|
|
30772 0.003 0.000 0.003 0.000 {method 'get' of 'dict' objects}
|
|
...
|
|
|
|
The bottom of the output shows the top most time consuming functions,
|
|
slowest on top. The profiling support is from Python's built-in tool,
|
|
`cProfile
|
|
<https://docs.python.org/2/library/profile.html#module-cProfile>`_.
|