diff --git a/tutorial_configuration.rst b/tutorial_configuration.rst index 77b1e7115..4bc1228a6 100644 --- a/tutorial_configuration.rst +++ b/tutorial_configuration.rst @@ -55,7 +55,7 @@ Configuration from the command line ----------------------------------- You can run ``spack config blame [section]`` at any point in time to see what your current configuration is. -If you omit the section, then spack will dump all the configurations settings to your screen. +If you omit the section, then Spack will dump all the configuration settings to your screen. Let's go ahead and run this for the ``concretizer`` section. .. code-block:: console @@ -248,7 +248,7 @@ We can do this by adding creating a toolchain config: - spec: '%fortran=gcc@11.4.0' when: '%fortran' -We are essentially saying "use Clang for c/c++, and use GCC for Fortran". +We are essentially saying "use Clang for C/C++, and use GCC for Fortran". You can use this new entry like so: .. code-block:: spec diff --git a/tutorial_developer_workflows.rst b/tutorial_developer_workflows.rst index b1b7f140f..8b6f5b60e 100644 --- a/tutorial_developer_workflows.rst +++ b/tutorial_developer_workflows.rst @@ -147,7 +147,7 @@ In this case, it will be the 2.0.0 release that we want to write a patch for: The ``spack develop`` command marks the package as being a "development" package based on the supplied ``develop spec``. Develop specs are listed in their own ``develop`` section inside the ``spack.yaml``. -The mechanics of how this section is used to enforce develpoment are as follows: +The mechanics of how this section is used to enforce development are as follows: 1. Specs in the environment that ``satisfy`` the develop specs are selected for development. 2. Any specs selected in step 1 receive a ``dev_path=`` variant. @@ -156,8 +156,8 @@ The mechanics of how this section is used to enforce develpoment are as follows: 3. Calls to ``spack install`` will now use the source code at ``dev_path`` when building that package. 4. Spack doesn't clean this build up after a successful build so subsequent calls to ``spack install`` trigger incremental builds. -If the environment is already concretized ``spack develop`` performs step 1 and 2 in situ and updates the ``spack.lock`` file by default. -If the environment is not yet concretized the selection of develop specs and assignment of ``dev_path`` are handled during concretization. +If the environment is already concretized, ``spack develop`` performs step 1 and 2 in situ and updates the ``spack.lock`` file by default. +If the environment is not yet concretized, the selection of develop specs and assignment of ``dev_path`` are handled during concretization. So how does Spack determine the value of the ``dev_path`` variant? By default, the source code is downloaded into a subdirectory of the environment using Spack's staging functionality. @@ -235,7 +235,7 @@ So far all of our calls to ``spack develop`` have been on a concretized environm If we don't want Spack to update the concrete environment's specs we can pass the ``---no-modify-concrete-spec``. Using ``---no-modify-concrete-spec`` will require you to force concretize an environment to have the develop specs take affect. -There are a limited set of use-cases where one might want to use this option. +There is a limited set of use-cases where one might want to use this option. Some example cases include: - Updating a develop spec before updating the environment to change a variant or version diff --git a/tutorial_environments.rst b/tutorial_environments.rst index 0ddb33560..a7abc3acb 100644 --- a/tutorial_environments.rst +++ b/tutorial_environments.rst @@ -181,7 +181,7 @@ Using Packages Spack environments provide a convenient way to use your installed packages by automatically making them available in your shell environment. This is accomplished through a feature called **environment views**. -An environment view is a directory structure mirroring a standard linux root filesystem with directories like ``/bin`` and ``/usr`` that contain symbolic links to all the packages installed in your Spack environment. +An environment view is a directory structure mirroring a standard Linux root filesystem with directories like ``/bin`` and ``/usr`` that contain symbolic links to all the packages installed in your Spack environment. When you activate an environment with ``spack env activate``, Spack automatically: * Prepends the view's ``bin`` directory to your ``PATH`` environment variable diff --git a/tutorial_modules.rst b/tutorial_modules.rst index 4703c81e5..83bc1f399 100644 --- a/tutorial_modules.rst +++ b/tutorial_modules.rst @@ -13,7 +13,7 @@ Module Files Tutorial This tutorial illustrates how Spack can be used to generate module files for the software that has been installed. Both hierarchical and non-hierarchical deployments will be discussed in detail and we will show how to customize the content and naming of each module file. -At the end of the tutorial readers should have a clear understanding of: +At the end of the tutorial, readers will have a clear understanding of: * What module files are and how they are used on HPC clusters * How Spack generates module files for the software it installs @@ -178,7 +178,7 @@ For further details we refer to its `documentation