Skip to content

Commit 739f5d6

Browse files
committed
each sentence on one line
Signed-off-by: Todd Gamblin <tgamblin@llnl.gov>
1 parent 9d30624 commit 739f5d6

1 file changed

Lines changed: 33 additions & 56 deletions

File tree

tutorial_basics.rst

Lines changed: 33 additions & 56 deletions
Original file line numberDiff line numberDiff line change
@@ -72,34 +72,24 @@ Let's go ahead and install ``gmake``,
7272
.. literalinclude:: outputs/basics/gmake.out
7373
:language: console
7474

75-
You will see Spack installed ``gmake``, ``gcc``, ``gcc-runtime``, and
76-
``glibc``. The ``glibc`` and ``gcc-runtime`` packages are
77-
automatically tracked by Spack to manage consistency requirements
78-
among compiler runtimes. These do not represent separate software
79-
builds from source, but are records of the compiler runtime components
80-
Spack used for the install. For the rest of this section, we'll ignore
81-
these components and focus on the packages explicitly installed and
82-
their listed dependencies.
83-
84-
The ``gcc`` package was found on the system and Spack used it because
85-
``gmake`` requires a compiler to build from source. Compilers are
86-
handled somewhat specially in Spack; Spack searches the ``PATH``
87-
environment variable for compilers automatically. We can run ``spack
88-
compiler list`` or simply ``spack compilers`` to show all the
89-
compilers Spack found.
75+
You will see Spack installed ``gmake``, ``gcc``, ``gcc-runtime``, and ``glibc``.
76+
The ``glibc`` and ``gcc-runtime`` packages are automatically tracked by Spack to manage consistency requirements among compiler runtimes.
77+
These do not represent separate software builds from source, but are records of the compiler runtime components Spack used for the install.
78+
For the rest of this section, we'll ignore these components and focus on the packages explicitly installed and their listed dependencies.
79+
80+
The ``gcc`` package was found on the system and Spack used it because ``gmake`` requires a compiler to build from source.
81+
Compilers are handled somewhat specially in Spack; Spack searches the ``PATH`` environment variable for compilers automatically.
82+
We can run ``spack compiler list`` or simply ``spack compilers`` to show all the compilers Spack found.
9083

9184
.. literalinclude:: outputs/basics/compiler-list.out
9285
:language: console
9386

94-
All compilers that Spack found will be configured as external packages
95-
-- we'll talk more about externals in the "Spack Concepts" slides and
96-
in :ref:`Configuration Tutorial <configs-tutorial>` later on.
87+
All compilers that Spack found will be configured as external packages -- we'll talk more about externals in the "Spack Concepts" slides and in :ref:`Configuration Tutorial <configs-tutorial>` later on.
9788

98-
Spack can install software either from source or from a binary
99-
cache. Packages in the binary cache are signed with GPG for
100-
security. For this tutorial we have prepared a binary cache so we
101-
don't have to wait for slow compilation from source. To enable installation from the binary cache, we'll need to configure Spack with
102-
the location of the cache and trust the GPG key that the binaries were signed with.
89+
Spack can install software either from source or from a binary cache.
90+
Packages in the binary cache are signed with GPG for security.
91+
For this tutorial we have prepared a binary cache so we don't have to wait for slow compilation from source.
92+
To enable installation from the binary cache, we'll need to configure Spack with the location of the cache and trust the GPG key that the binaries were signed with.
10393

10494
.. literalinclude:: outputs/basics/mirror.out
10595
:language: console
@@ -130,8 +120,7 @@ The ``@`` sigil is used to specify versions.
130120
.. literalinclude:: outputs/basics/zlib-2.0.7.out
131121
:language: console
132122

133-
The spec syntax is recursive -- any syntax we can specify for the
134-
"root" package (``zlib-ng``) we can also use for a dependency.
123+
The spec syntax is recursive -- any syntax we can specify for the "root" package (``zlib-ng``) we can also use for a dependency.
135124

136125
.. literalinclude:: outputs/basics/zlib-gcc-10.out
137126
:language: console
@@ -166,12 +155,9 @@ This approach helps us avoid unnecessary rebuilds of common dependencies, which
166155
.. literalinclude:: outputs/basics/tcl.out
167156
:language: console
168157

169-
Sometimes it is simpler to specify dependencies without caring whether
170-
they are direct or transitive dependencies. To do that, use the ``^``
171-
sigil. Note that a dependency specified by ``^`` is always applied to
172-
the root package, whereas a direct dependency specified by ``%`` is
173-
applied to either the root or any intervening dependency specified by
174-
``^``.
158+
Sometimes it is simpler to specify dependencies without caring whether they are direct or transitive dependencies.
159+
To do that, use the ``^`` sigil.
160+
Note that a dependency specified by ``^`` is always applied to the root package, whereas a direct dependency specified by ``%`` is applied to either the root or any intervening dependency specified by ``^``.
175161

176162
.. literalinclude:: outputs/basics/tcl-zlib-clang.out
177163
:language: console
@@ -192,21 +178,18 @@ Note that each package has a top-level entry, even if it also appears as a depen
192178
.. literalinclude:: outputs/basics/find-ldf.out
193179
:language: console
194180

195-
Spack models the dependencies of packages as a directed acyclic graph
196-
(DAG). The ``spack find -d`` command shows the tree representation of
197-
that graph, which loses some dependency relationship information. We
198-
can also use the ``spack graph`` command to view the entire DAG as a
199-
graph.
181+
Spack models the dependencies of packages as a directed acyclic graph (DAG).
182+
The ``spack find -d`` command shows the tree representation of that graph, which loses some dependency relationship information.
183+
We can also use the ``spack graph`` command to view the entire DAG as a graph.
200184

201185
.. literalinclude:: outputs/basics/graph-tcl.out
202186
:language: console
203187

204-
Let's move on to slightly more complicated packages. HDF5 is a good
205-
example of a more complicated package, with an MPI dependency. If we
206-
install it with default settings it will build with OpenMPI. We can
207-
check the install plan in advance to ensure it's what we want to
208-
install using the ``spack spec`` command. The ``spack spec`` command
209-
accepts the same spec syntax.
188+
Let's move on to slightly more complicated packages.
189+
HDF5 is a good example of a more complicated package, with an MPI dependency.
190+
If we install it with default settings it will build with OpenMPI.
191+
We can check the install plan in advance to ensure it's what we want to install using the ``spack spec`` command.
192+
The ``spack spec`` command accepts the same spec syntax.
210193

211194
.. literalinclude:: outputs/basics/hdf5-spec.out
212195
:language: console
@@ -236,20 +219,14 @@ Spack also supports versioning of virtual dependencies.
236219
A package can depend on the MPI interface at version 3 (e.g., ``hdf5 ^mpi@3``), and provider packages specify what version of the interface *they* provide.
237220
The partial spec ``^mpi@3`` can be satisfied by any of several MPI implementation packages that provide MPI version 3.
238221

239-
We've actually already been using virtual packages when we changed
240-
compilers earlier. Compilers are providers for virtual packages like
241-
``c``, ``cxx``, and ``fortran``. Because these are often provided by
242-
the same package but we might want to use C and C++ from one compiler
243-
and Fortran from another, we need a syntax to specify which virtual a
244-
package provides. We call this "virtual assignment", and can be
245-
specified by ``%virtual=provider`` or ``^virtual=provider``.
246-
247-
We will now install HDF5 with MPI support provided by MPICH, ensuring
248-
that the C and C++ components of HDF5 are compiled with ``gcc``. We
249-
could use the same syntax for ``^mpi=mpich``, but there's no need
250-
because the only way for ``hdf5`` to depend on ``mpich`` is to provide
251-
``mpi``. This is also why we didn't care to specify which virtuals
252-
``gcc`` and ``clang`` provided earlier when building simpler packages.
222+
We've actually already been using virtual packages when we changed compilers earlier.
223+
Compilers are providers for virtual packages like ``c``, ``cxx``, and ``fortran``.
224+
Because these are often provided by the same package but we might want to use C and C++ from one compiler and Fortran from another, we need a syntax to specify which virtual a package provides.
225+
We call this "virtual assignment", and can be specified by ``%virtual=provider`` or ``^virtual=provider``.
226+
227+
We will now install HDF5 with MPI support provided by MPICH, ensuring that the C and C++ components of HDF5 are compiled with ``gcc``.
228+
We could use the same syntax for ``^mpi=mpich``, but there's no need because the only way for ``hdf5`` to depend on ``mpich`` is to provide ``mpi``.
229+
This is also why we didn't care to specify which virtuals ``gcc`` and ``clang`` provided earlier when building simpler packages.
253230

254231
.. literalinclude:: outputs/basics/hdf5-hl-mpi.out
255232
:language: console

0 commit comments

Comments
 (0)