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

Fix typos.

Browse Source 
Thanks Adam!
This commit is contained in:
Todd Gamblin 2014-07-08 02:41:29 -07:00
parent 830b9ab25c
commit bd8838ca6d
2 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -281,7 +281,7 @@ of its dependencies, simply run ``spack install <package>``:
spack install mpileaks spack install mpileaks
Spack will fetch the tarball for ``mpileaks``, expand it, verify that Spack will fetch the tarball for ``mpileaks``, expand it, verify that
it was donwloaded without errors, build it, and install it in its own it was downloaded without errors, build it, and install it in its own
directory under ``$SPACK_HOME/opt``. If the requested package depends directory under ``$SPACK_HOME/opt``. If the requested package depends
on other packages in order to build, Spack fetches them as well, and on other packages in order to build, Spack fetches them as well, and
installs them before it installs the requested package. Like the main installs them before it installs the requested package. Like the main
@ -380,12 +380,12 @@ More formally, a spec consists of the following pieces:
* ``=`` Optional architecture specifier (``bgqos_0``) * ``=`` Optional architecture specifier (``bgqos_0``)
* ``^`` Dependency specs (``^callpath@1.1``) * ``^`` Dependency specs (``^callpath@1.1``)
There are two things to notice here. One is that specs are There are two things to notice here. The first is that specs are
recursively defined. That is, each dependency after ``^`` is a spec recursively defined. That is, each dependency after ``^`` is a spec
itself. The second is that Notice that everything is optional itself. The second is that everything is optional *except* for the
*except* for the initial package name identifier. Users can be as initial package name identifier. Users can be as vague or as specific
vague or as specific as they want about the details of building as they want about the details of building packages, and this makes
packages, and this makes spack good for beginners and experts alike. spack good for beginners and experts alike.
To really understand what's going on above, we need to think about how To really understand what's going on above, we need to think about how
software is structured. An executable or a library (these are software is structured. An executable or a library (these are
@ -605,12 +605,12 @@ getting info on it:
Spack is unique in that its virtual packages can be versioned, just Spack is unique in that its virtual packages can be versioned, just
like regular packages. A particular version of a package may provide like regular packages. A particular version of a package may provide
a particular version of a virtual package, and we can see above that a particular version of a virtual package, and we can see above that
``mpich`` versions ``1`` and above provide all interfaces up to ``1``, ``mpich`` versions ``1`` and above provide all ``mpi`` interface
and ``mpich`` versions ``3`` and above provide ``mpi`` versions up to versions up to ``1``, and ``mpich`` versions ``3`` and above provide
``3``. A package can *depend on* a particular version of a virtual ``mpi`` versions up to ``3``. A package can *depend on* a particular
package, e.g. if an application needs MPI-2 functions, it can depend version of a virtual package, e.g. if an application needs MPI-2
on ``mpi@2:`` to indicate that it needs some implementation that functions, it can depend on ``mpi@2:`` to indicate that it needs some
provides MPI-2 functions. implementation that provides MPI-2 functions.
Constraining virtual packages Constraining virtual packages

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

@ -636,7 +636,7 @@ Spack parses the command line and builds a spec from the description.
The spec says that ``mpileaks`` should be built with the ``callpath`` The spec says that ``mpileaks`` should be built with the ``callpath``
library at 1.0 and with the debug option enabled, and with ``libelf`` library at 1.0 and with the debug option enabled, and with ``libelf``
version 0.8.11. Spack will also look at the ``depends_on`` calls in version 0.8.11. Spack will also look at the ``depends_on`` calls in
all of these packags, and it will build a spec from that. The specs all of these packages, and it will build a spec from that. The specs
from the command line and the specs built from package descriptions from the command line and the specs built from package descriptions
are then combined, and the constraints are checked against each other are then combined, and the constraints are checked against each other
to make sure they're satisfiable. to make sure they're satisfiable.
@ -871,9 +871,10 @@ directories that ``diff`` compared when it created the patch file.
This is git's default behavior when creating patch files, but other This is git's default behavior when creating patch files, but other
programs may behave differently. programs may behave differently.
``-p1`` strings off the first level of prefix in both paths, allowing ``-p1`` strips off the first level of the prefix in both paths,
the patch to be applied from the root of an expanded mvapich2 archive. allowing the patch to be applied from the root of an expanded mvapich2
If you set level to ``2``, it would strip off ``src``, and so on. archive. If you set level to ``2``, it would strip off ``src``, and
so on.
It's generally easier to just structure your patch file so that it It's generally easier to just structure your patch file so that it
applies cleanly with ``-p1``, but if you're using a URL to a patch you applies cleanly with ``-p1``, but if you're using a URL to a patch you
@ -996,8 +997,8 @@ Testing spec constraints
You can test whether your spec is configured a certain way by using You can test whether your spec is configured a certain way by using
the ``satisfies`` method. For example, if you want to check whether the ``satisfies`` method. For example, if you want to check whether
the pcakage is at a particular version range, you can use specs to do the package's version is in a particular range, you can use specs to
that, e.g.: do that, e.g.:
.. code-block:: python .. code-block:: python
@ -1287,7 +1288,7 @@ already been expanded, ``stage`` is idempotent.
After staging, Spack applies patches to downloaded packages, if any After staging, Spack applies patches to downloaded packages, if any
have been specified in the package file. This command will run the have been specified in the package file. This command will run the
install process throught he fetch, stage, and patch phases. Spack install process through the fetch, stage, and patch phases. Spack
keeps track of whether patches have already been applied and skips keeps track of whether patches have already been applied and skips
this step if they have been. If Spack discovers that patches didn't this step if they have been. If Spack discovers that patches didn't
apply cleanly on some previous run, then it will restage the entire apply cleanly on some previous run, then it will restage the entire