diff options
Diffstat (limited to 'lib/spack/docs/packaging_guide.rst')
| -rw-r--r-- | lib/spack/docs/packaging_guide.rst | 140 |
1 files changed, 97 insertions, 43 deletions
diff --git a/lib/spack/docs/packaging_guide.rst b/lib/spack/docs/packaging_guide.rst index 6cea4da14f..a0d0feabbd 100644 --- a/lib/spack/docs/packaging_guide.rst +++ b/lib/spack/docs/packaging_guide.rst @@ -36,10 +36,11 @@ Creating & editing packages ``spack create`` ~~~~~~~~~~~~~~~~~~~~~ -The ``spack create`` command generates a boilerplate package template -from a URL. The URL should point to a tarball or other software -archive. In most cases, ``spack create`` plus a few modifications is -all you need to get a package working. +The ``spack create`` command creates a directory with the package name and +generates a ``package.py`` file with a boilerplate package template from a URL. +The URL should point to a tarball or other software archive. In most cases, +``spack create`` plus a few modifications is all you need to get a package +working. Here's an example: @@ -47,12 +48,16 @@ Here's an example: $ spack create http://www.cmake.org/files/v2.8/cmake-2.8.12.1.tar.gz -Spack examines the tarball URL and tries to figure out the name of the -package to be created. It also tries to determine what version strings -look like for this package. Using this information, it will try to -find *additional* versions by spidering the package's webpage. If it -finds multiple versions, Spack prompts you to tell it how many -versions you want to download and checksum: +Spack examines the tarball URL and tries to figure out the name of the package +to be created. Once the name is determined a directory in the appropriate +repository is created with that name. Spack prefers, but does not require, that +names be lower case so the directory name will be lower case when ``spack +create`` generates it. In cases where it is desired to have mixed case or upper +case simply rename the directory. Spack also tries to determine what version +strings look like for this package. Using this information, it will try to find +*additional* versions by spidering the package's webpage. If it finds multiple +versions, Spack prompts you to tell it how many versions you want to download +and checksum: .. code-block:: sh @@ -297,9 +302,10 @@ directories or files (like patches) that it needs to build. Package Names ~~~~~~~~~~~~~~~~~~ -Packages are named after the directory containing ``package.py``. So, -``libelf``'s ``package.py`` lives in a directory called ``libelf``. -The ``package.py`` file defines a class called ``Libelf``, which +Packages are named after the directory containing ``package.py``. It is +preferred, but not required, that the directory, and thus the package name, are +lower case. So, ``libelf``'s ``package.py`` lives in a directory called +``libelf``. The ``package.py`` file defines a class called ``Libelf``, which extends Spack's ``Package`` class. for example, here is ``$SPACK_ROOT/var/spack/repos/builtin/packages/libelf/package.py``: @@ -562,7 +568,7 @@ The package author is responsible for coming up with a sensible name for each version to be fetched from a repository. For example, if you're fetching from a tag like ``v1.0``, you might call that ``1.0``. If you're fetching a nameless git commit or an older subversion -revision, you might give the commit an intuitive name, like ``dev`` +revision, you might give the commit an intuitive name, like ``develop`` for a development version, or ``some-fancy-new-feature`` if you want to be more specific. @@ -572,6 +578,17 @@ branches move forward over time and you aren't guaranteed to get the same thing every time you fetch a particular version. Life isn't always simple, though, so this is not strictly enforced. +When fetching from from the branch corresponding to the development version +(often called ``master``,``trunk`` or ``dev``), it is recommended to +call this version ``develop``. Spack has special treatment for this version so + that ``@develop`` will satisfy dependencies like +``depends_on(abc, when="@x.y.z:")``. In other words, ``@develop`` is +greater than any other version. The rationale is that certain features or +options first appear in the development branch. Therefore if a package author +wants to keep the package on the bleeding edge and provide support for new +features, it is advised to use ``develop`` for such a version which will +greatly simplify writing dependencies and version-related conditionals. + In some future release, Spack may support extrapolating repository versions as it does for tarball URLs, but currently this is not supported. @@ -587,6 +604,7 @@ Git fetching is enabled with the following parameters to ``version``: * ``tag``: name of a tag to fetch. * ``branch``: name of a branch to fetch. * ``commit``: SHA hash (or prefix) of a commit to fetch. + * ``submodules``: Also fetch submodules when checking out this repository. Only one of ``tag``, ``branch``, or ``commit`` can be used at a time. @@ -597,7 +615,7 @@ Default branch class Example(Package): ... - version('dev', git='https://github.com/example-project/example.git') + version('develop', git='https://github.com/example-project/example.git') This is not recommended, as the contents of the default branch change over time. @@ -643,6 +661,17 @@ Commits could just use the abbreviated commit hash. It's up to the package author to decide what makes the most sense. +Submodules + + You can supply ``submodules=True`` to cause Spack to fetch submodules + along with the repository at fetch time. + + .. code-block:: python + + version('1.0.1', git='https://github.com/example-project/example.git', + tag='v1.0.1', submdoules=True) + + Installing ^^^^^^^^^^^^^^ @@ -670,7 +699,7 @@ Default .. code-block:: python - version('hg-head', hg='https://jay.grs.rwth-aachen.de/hg/example') + version('develop', hg='https://jay.grs.rwth-aachen.de/hg/example') Note that this is not recommended; try to fetch a particular revision instead. @@ -702,7 +731,7 @@ Fetching the head .. code-block:: python - version('svn-head', svn='https://outreach.scidac.gov/svn/libmonitor/trunk') + version('develop', svn='https://outreach.scidac.gov/svn/libmonitor/trunk') This is not recommended, as the head will move forward over time. @@ -712,7 +741,7 @@ Fetching a revision .. code-block:: python - version('svn-head', svn='https://outreach.scidac.gov/svn/libmonitor/trunk', + version('develop', svn='https://outreach.scidac.gov/svn/libmonitor/trunk', revision=128) Subversion branches are handled as part of the directory structure, so @@ -1257,6 +1286,31 @@ command line to find installed packages or to install packages with particular constraints, and package authors can use specs to describe relationships between packages. +Additionally, dependencies may be specified for specific use cases: + +.. code-block:: python + + depends_on("cmake", type="build") + depends_on("libelf", type=("build", "link")) + depends_on("python", type="run") + +The dependency types are: + + * **"build"**: made available during the project's build. The package will + be added to ``PATH``, the compiler include paths, and ``PYTHONPATH``. + Other projects which depend on this one will not have these modified + (building project X doesn't need project Y's build dependencies). + * **"link"**: the project is linked to by the project. The package will be + added to the current package's ``rpath``. + * **"run"**: the project is used by the project at runtime. The package will + be added to ``PATH`` and ``PYTHONPATH``. + +If not specified, ``type`` is assumed to be ``("build", "link")``. This is the +common case for compiled language usage. Also available are the aliases +``alldeps`` for all dependency types and ``nolink`` (``("build", "run")``) for +use by dependencies which are not expressed via a linker (e.g., Python or Lua +module loading). + .. _setup-dependent-environment: ``setup_dependent_environment()`` @@ -1660,21 +1714,21 @@ the user runs ``spack install`` and the time the ``install()`` method is called. The concretized version of the spec above might look like this:: - mpileaks@2.3%gcc@4.7.3 arch=linux-ppc64 - ^callpath@1.0%gcc@4.7.3+debug arch=linux-ppc64 - ^dyninst@8.1.2%gcc@4.7.3 arch=linux-ppc64 - ^libdwarf@20130729%gcc@4.7.3 arch=linux-ppc64 - ^libelf@0.8.11%gcc@4.7.3 arch=linux-ppc64 - ^mpich@3.0.4%gcc@4.7.3 arch=linux-ppc64 + mpileaks@2.3%gcc@4.7.3 arch=linux-debian7-x86_64 + ^callpath@1.0%gcc@4.7.3+debug arch=linux-debian7-x86_64 + ^dyninst@8.1.2%gcc@4.7.3 arch=linux-debian7-x86_64 + ^libdwarf@20130729%gcc@4.7.3 arch=linux-debian7-x86_64 + ^libelf@0.8.11%gcc@4.7.3 arch=linux-debian7-x86_64 + ^mpich@3.0.4%gcc@4.7.3 arch=linux-debian7-x86_64 .. graphviz:: digraph { - "mpileaks@2.3\n%gcc@4.7.3\n arch=linux-ppc64" -> "mpich@3.0.4\n%gcc@4.7.3\n arch=linux-ppc64" - "mpileaks@2.3\n%gcc@4.7.3\n arch=linux-ppc64" -> "callpath@1.0\n%gcc@4.7.3+debug\n arch=linux-ppc64" -> "mpich@3.0.4\n%gcc@4.7.3\n arch=linux-ppc64" - "callpath@1.0\n%gcc@4.7.3+debug\n arch=linux-ppc64" -> "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-ppc64" - "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-ppc64" -> "libdwarf@20130729\n%gcc@4.7.3\n arch=linux-ppc64" -> "libelf@0.8.11\n%gcc@4.7.3\n arch=linux-ppc64" - "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-ppc64" -> "libelf@0.8.11\n%gcc@4.7.3\n arch=linux-ppc64" + "mpileaks@2.3\n%gcc@4.7.3\n arch=linux-debian7-x86_64" -> "mpich@3.0.4\n%gcc@4.7.3\n arch=linux-debian7-x86_64" + "mpileaks@2.3\n%gcc@4.7.3\n arch=linux-debian7-x86_64" -> "callpath@1.0\n%gcc@4.7.3+debug\n arch=linux-debian7-x86_64" -> "mpich@3.0.4\n%gcc@4.7.3\n arch=linux-debian7-x86_64" + "callpath@1.0\n%gcc@4.7.3+debug\n arch=linux-debian7-x86_64" -> "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-debian7-x86_64" + "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-debian7-x86_64" -> "libdwarf@20130729\n%gcc@4.7.3\n arch=linux-debian7-x86_64" -> "libelf@0.8.11\n%gcc@4.7.3\n arch=linux-debian7-x86_64" + "dyninst@8.1.2\n%gcc@4.7.3\n arch=linux-debian7-x86_64" -> "libelf@0.8.11\n%gcc@4.7.3\n arch=linux-debian7-x86_64" } Here, all versions, compilers, and platforms are filled in, and there @@ -1703,9 +1757,9 @@ running ``spack spec``. For example: ^libdwarf ^libelf - dyninst@8.0.1%gcc@4.7.3 arch=linux-ppc64 - ^libdwarf@20130729%gcc@4.7.3 arch=linux-ppc64 - ^libelf@0.8.13%gcc@4.7.3 arch=linux-ppc64 + dyninst@8.0.1%gcc@4.7.3 arch=linux-debian7-x86_64 + ^libdwarf@20130729%gcc@4.7.3 arch=linux-debian7-x86_64 + ^libelf@0.8.13%gcc@4.7.3 arch=linux-debian7-x86_64 This is useful when you want to know exactly what Spack will do when you ask for a particular spec. @@ -2210,12 +2264,12 @@ example: def install(self, prefix): # Do default install - @when('arch=chaos_5_x86_64_ib') + @when('arch=linux-debian7-x86_64') def install(self, prefix): # This will be executed instead of the default install if # the package's sys_type() is chaos_5_x86_64_ib. - @when('arch=bgqos_0") + @when('arch=linux-debian7-x86_64") def install(self, prefix): # This will be executed if the package's sys_type is bgqos_0 @@ -2343,7 +2397,7 @@ build system. .. _sanity-checks: -Sanity checking an intallation +Sanity checking an installation -------------------------------- By default, Spack assumes that a build has failed if nothing is @@ -2706,15 +2760,15 @@ build process will start from scratch. ``spack purge`` ~~~~~~~~~~~~~~~~~ -Cleans up all of Spack's temporary and cached files. This can be used to -recover disk space if temporary files from interrupted or failed installs -accumulate in the staging area. +Cleans up all of Spack's temporary and cached files. This can be used to +recover disk space if temporary files from interrupted or failed installs +accumulate in the staging area. When called with ``--stage`` or ``--all`` (or without arguments, in which case -the default is ``--all``) this removes all staged files; this is equivalent to +the default is ``--all``) this removes all staged files; this is equivalent to running ``spack clean`` for every package you have fetched or staged. -When called with ``--cache`` or ``--all`` this will clear all resources +When called with ``--cache`` or ``--all`` this will clear all resources :ref:`cached <caching>` during installs. Keeping the stage directory on success @@ -2863,11 +2917,11 @@ build it: $ spack stage libelf ==> Trying to fetch from http://www.mr511.de/software/libelf-0.8.13.tar.gz ######################################################################## 100.0% - ==> Staging archive: /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-ppc64/libelf-0.8.13.tar.gz - ==> Created stage in /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-ppc64. + ==> Staging archive: /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-debian7-x86_64/libelf-0.8.13.tar.gz + ==> Created stage in /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-debian7-x86_64. $ spack cd libelf $ pwd - /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-ppc64/libelf-0.8.13 + /Users/gamblin2/src/spack/var/spack/stage/libelf@0.8.13%gcc@4.8.3 arch=linux-debian7-x86_64/libelf-0.8.13 ``spack cd`` here changed he current working directory to the directory containing the expanded ``libelf`` source code. There are a |