zhangyiss/spack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Starting on packaging docs.

Browse Source
This commit is contained in:
Todd Gamblin
2013-12-25 15:30:42 -08:00
parent 354c8a281b
commit 4ff8766a22
3 changed files with 98 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
lib/spack/docs/basic_usage.rst
View File

@@ -1,3 +1,5 @@
.. _basic_usage:
Basic usage
=====================
@@ -564,76 +566,3 @@ add a version specifier to the spec:
Notice that the package versions that provide insufficient MPI
versions are now filtered out.
Package lifecycle
------------------------------
``spack install`` command performs a number of tasks before it finally
installs each package. It downloads an archive, expands it in a
temporary directory, and then performs the installation. Spack has
several commands that allow finer-grained control over each stage of
the build process.
``spack fetch``
~~~~~~~~~~~~~~~~~
The first step of ``spack install``. Takes a spec and determines the
correct download URL to use for the requested package version, then
downloads the archive, checks it against an MD5 checksum, and stores
it in a staging directory if the check was successful. The staging
directory will be located under ``$SPACK_HOME/var/spack``.
When run after the archive has already been downloaded, ``spack
fetch`` is idempotent and will not download the archive again.
``spack stage``
~~~~~~~~~~~~~~~~~
The second step in ``spack install`` after ``spack fetch``. Expands
the downloaded archive in its temporary directory, where it will be
built by ``spack install``. Similar to ``fetch``, if the archive has
already been expanded, ``stage`` is idempotent.
``spack clean``
~~~~~~~~~~~~~~~~~
There are several variations of ``spack clean``. With no arguments,
``spack clean`` runs ``make clean`` in the expanded archive directory.
This is useful if an attempted build failed, and something needs to be
changed to get a package to build. If a particular package does not
have a ``make clean`` target, this will do nothing.
``spack clean -w / --work``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deletes the entire build directory and re-expands it from the downloaded
archive. This is useful if a package does not support a proper ``make clean``
target.
``spack clean -d / --dist``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deletes the build directory *and* the downloaded archive. If
``fetch``, ``stage``, or ``install`` are run again after this, the
process will start from scratch, and the archive archive will be
downloaded again. Useful if somehow a bad archive is downloaded
accidentally and needs to be cleaned out of the staging area.
``spack purge``
~~~~~~~~~~~~~~~~~
Cleans up *everything* in the build directory. You can use this to
recover disk space if temporary files from interrupted or failed
installs accumulate in the staging area.
Dirty Installs
~~~~~~~~~~~~~~~~~~~
By default, ``spack install`` will delete the staging area once a
pacakge has been successfully built and installed, *or* if an error
occurs during the build. Use ``spack install --dirty`` or ``spack
install -d`` to leave the build directory intact. This allows you to
inspect the build directory and potentially fix the build. You can
use ``purge`` or ``clean`` later to get rid of the unwanted temporary
files.

3
lib/spack/docs/conf.py
View File

@@ -19,7 +19,8 @@
sys.path.insert(0, os.path.abspath('exts'))
# Add the Spack bin directory to the path so that we can use its output in docs.
os.environ['PATH'] += os.pathsep + '../../../bin'
os.environ['SPACK_ROOT'] = '../../..'
os.environ['PATH'] += os.pathsep + '$SPACK_ROOT/bin'
# Set an environment variable so that colify will print output like it would to
# a terminal.

97
lib/spack/docs/packaging_guide.rst
View File

@@ -1,18 +1,109 @@
Packaging Guide
=====================
This guide is intended for developers or administrators who want to
*package* their software so that Spack can install it. We assume that
you have at least some familiarty with Python, and that you've read
the :ref:`guide for regular users <basic_usage>`, especially the part
about *specs*.
Package files
-------------------------
There are two parts of Spack, a language for describing builds of
software (*specs*), and *packages*: Python modules thatactually build
the software. A package essentially takes a spec and implements it
for a particular piece of software. It allows a developer to
encapsulate build logic for different versions, compilers, and
platforms in one place, and it is designed to make things easy for
you, the packager, as much as possible.
Packages in spack live in ``$prefix/lib/spack/spack/packages``:
.. command-output:: cd $SPACK_ROOT/lib/spack/spack/packages; ls *.py
:shell:
:ellipsis: 5
Package lifecycle
------------------------------
``spack install`` command performs a number of tasks before it finally
installs each package. It downloads an archive, expands it in a
temporary directory, and then performs the installation. Spack has
several commands that allow finer-grained control over each stage of
the build process.
``spack fetch``
~~~~~~~~~~~~~~~~~
The first step of ``spack install``. Takes a spec and determines the
correct download URL to use for the requested package version, then
downloads the archive, checks it against an MD5 checksum, and stores
it in a staging directory if the check was successful. The staging
directory will be located under ``$SPACK_HOME/var/spack``.
When run after the archive has already been downloaded, ``spack
fetch`` is idempotent and will not download the archive again.
``spack stage``
~~~~~~~~~~~~~~~~~
The second step in ``spack install`` after ``spack fetch``. Expands
the downloaded archive in its temporary directory, where it will be
built by ``spack install``. Similar to ``fetch``, if the archive has
already been expanded, ``stage`` is idempotent.
``spack clean``
~~~~~~~~~~~~~~~~~
There are several variations of ``spack clean``. With no arguments,
``spack clean`` runs ``make clean`` in the expanded archive directory.
This is useful if an attempted build failed, and something needs to be
changed to get a package to build. If a particular package does not
have a ``make clean`` target, this will do nothing.
``spack clean -w / --work``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deletes the entire build directory and re-expands it from the downloaded
archive. This is useful if a package does not support a proper ``make clean``
target.
``spack clean -d / --dist``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deletes the build directory *and* the downloaded archive. If
``fetch``, ``stage``, or ``install`` are run again after this, the
process will start from scratch, and the archive archive will be
downloaded again. Useful if somehow a bad archive is downloaded
accidentally and needs to be cleaned out of the staging area.
``spack purge``
~~~~~~~~~~~~~~~~~
Cleans up *everything* in the build directory. You can use this to
recover disk space if temporary files from interrupted or failed
installs accumulate in the staging area.
Dirty Installs
~~~~~~~~~~~~~~~~~~~
By default, ``spack install`` will delete the staging area once a
pacakge has been successfully built and installed, *or* if an error
occurs during the build. Use ``spack install --dirty`` or ``spack
install -d`` to leave the build directory intact. This allows you to
inspect the build directory and potentially fix the build. You can
use ``purge`` or ``clean`` later to get rid of the unwanted temporary
files.
Dependencies
-------------------------
Virtual dependencies
-------------------------
Virtual dependencies
-------------------------