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 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
on other packages in order to build, Spack fetches them as well, and
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``)
* ``^`` 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
itself. The second is that Notice that everything is optional
*except* for the initial package name identifier. Users can be as
vague or as specific as they want about the details of building
packages, and this makes spack good for beginners and experts alike.
itself. The second is that everything is optional *except* for the
initial package name identifier. Users can be as vague or as specific
as they want about the details of building packages, and this makes
spack good for beginners and experts alike.
To really understand what's going on above, we need to think about how
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
like regular packages. A particular version of a package may provide
a particular version of a virtual package, and we can see above that
``mpich`` versions ``1`` and above provide all interfaces up to ``1``,
and ``mpich`` versions ``3`` and above provide ``mpi`` versions up to
``3``. A package can *depend on* a particular version of a virtual
package, e.g. if an application needs MPI-2 functions, it can depend
on ``mpi@2:`` to indicate that it needs some implementation that
provides MPI-2 functions.
``mpich`` versions ``1`` and above provide all ``mpi`` interface
versions up to ``1``, and ``mpich`` versions ``3`` and above provide
``mpi`` versions up to ``3``. A package can *depend on* a particular
version of a virtual package, e.g. if an application needs MPI-2
functions, it can depend on ``mpi@2:`` to indicate that it needs some
implementation that provides MPI-2 functions.
Constraining virtual packages

13
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``
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
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
are then combined, and the constraints are checked against each other
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
programs may behave differently.
``-p1`` strings off the first level of prefix in both paths, allowing
the patch to be applied from the root of an expanded mvapich2 archive.
If you set level to ``2``, it would strip off ``src``, and so on.
``-p1`` strips off the first level of the prefix in both paths,
allowing the patch to be applied from the root of an expanded mvapich2
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
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
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
that, e.g.:
the package's version is in a particular range, you can use specs to
do that, e.g.:
.. code-block:: python