From bd8838ca6db5b1b234d42ce7175564645f5afa50 Mon Sep 17 00:00:00 2001 From: Todd Gamblin Date: Tue, 8 Jul 2014 02:41:29 -0700 Subject: Fix typos. Thanks Adam! --- lib/spack/docs/basic_usage.rst | 24 ++++++++++++------------ lib/spack/docs/packaging_guide.rst | 15 ++++++++------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/lib/spack/docs/basic_usage.rst b/lib/spack/docs/basic_usage.rst index f7f74a1623..71f3da8610 100644 --- a/lib/spack/docs/basic_usage.rst +++ b/lib/spack/docs/basic_usage.rst @@ -281,7 +281,7 @@ of its dependencies, simply run ``spack install ``: 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 diff --git a/lib/spack/docs/packaging_guide.rst b/lib/spack/docs/packaging_guide.rst index 023896b6c0..13785e25b7 100644 --- a/lib/spack/docs/packaging_guide.rst +++ b/lib/spack/docs/packaging_guide.rst @@ -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 @@ -1287,7 +1288,7 @@ already been expanded, ``stage`` is idempotent. After staging, Spack applies patches to downloaded packages, if any 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 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 -- cgit v1.2.3-60-g2f50