small tweaks and grammar corrections

doc/src/Build_basics.rst

@@ -495,7 +495,8 @@ It is also possible to create the HTML version of the manual within
 the :doc:`CMake build directory <Build_cmake>`.  The reason for this
 option is to include the installation of the HTML manual pages into
 the "install" step when installing LAMMPS after the CMake build via
-``make install``.
+``make install``.  The documentation build is included in the default
+build target, but can also be requested independently with ``make doc``.
 
 .. code-block:: bash
 

doc/src/Build_cmake.rst

@@ -101,11 +101,13 @@ Compiler Cache) software may speed up repeated compilation even more,
 e.g. during code development.
 
 After the initial build, whenever you edit LAMMPS source files, enable
-or disable packages, change compiler flags or build options,
-you must re-compile and relink the LAMMPS executable with ``cmake --build .``.
-If the compilation fails for some reason, try running ``cmake .`` and
-then compile again. The included dependency tracking should make certain
-that only the necessary subset of files are re-compiled.
+or disable packages, change compiler flags or build options, you must
+re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
+``make``).  If the compilation fails for some reason, try running
+``cmake .`` and then compile again. The included dependency tracking
+should make certain that only the necessary subset of files are
+re-compiled.  You can also delete compiled objects, libraries and
+executables with ``cmake --build . clean`` (or ``make clean``).
 
 After compilation, you may optionally install the LAMMPS executable into
 your system with:

doc/src/Build_development.rst

@@ -1,15 +1,15 @@
 Development build options (CMake only)
 ======================================
 
-The CMake build of LAMMPS has a few extra options which are useful during
-development, testing or debugging.
+The CMake build procedure of LAMMPS offers a few extra options which are
+useful during development, testing or debugging.
 
 ----------
 
 .. _compilation:
 
 Verify compilation flags
-------------------------------------------
+------------------------
 
 Sometimes it is necessary to verify the complete sequence of compilation flags
 generated by the CMake build. To enable a more verbose output during
@@ -30,7 +30,7 @@ Another way of doing this without reconfiguration is calling make with variable
 .. _sanitizer:
 
 Address, Undefined Behavior, and Thread Sanitizer Support
--------------------------------------------------------------------------
+---------------------------------------------------------
 
 Compilers such as GCC and Clang support generating instrumented binaries
 which use different sanitizer libraries to detect problems in code
@@ -41,10 +41,11 @@ during run-time. They can detect issues like:
  - `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_
 
 Please note that this kind of instrumentation usually comes with a small
-performance hit (much less than using tools like `Valgrind <valgrind_>`_).
-The to enable these features additional compiler flags need to be added
-to the compilation and linking stages.  This is most easily done through
-setting the ``CMAKE_TUNE_FLAGS`` variable during configuration. Examples:
+performance hit (much less than using tools like `Valgrind
+<https://valgrind.org>`_).  The to enable these features additional
+compiler flags need to be added to the compilation and linking stages.
+This is most easily done through setting the ``CMAKE_TUNE_FLAGS``
+variable during configuration. Examples:
 
 .. code-block:: bash
 
@@ -52,8 +53,6 @@ setting the ``CMAKE_TUNE_FLAGS`` variable during configuration. Examples:
    -D CMAKE_TUNE_FLAGS=-fsanitize=undefined  # enable undefined behavior sanitizer
    -D CMAKE_TUNE_FLAGS=-fsanitize=thread     # enable thread sanitizer
 
-.. _valgrind: https://valgrind.org
-
 ----------
 
 .. _testing:
@@ -75,24 +74,26 @@ developers can run the tests directly on their workstation.
    -D LAMMPS_TESTING_SOURCE_DIR=path     # path to lammps-testing repository (option if in custom location)
    -D LAMMPS_TESTING_GIT_TAG=value       # version of lammps-testing repository that should be used, value = master (default) or custom git commit or tag
 
-If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
+If you enable testing in the CMake build it will create an additional
+target called "test". You can run them with:
 
 .. code-block:: bash
 
-   make test
+   cmake --build . test
 
 The test cases used come from the lammps-testing repository. They are
-derivatives of the examples folder with some modifications to make the run
-faster.
+derivatives of the examples folder with some modifications to make the
+run faster.
 
-You can also collect code coverage metrics while running the tests by enabling
-coverage support during building.
+You can also collect code coverage metrics while running the tests by
+enabling coverage support during building.
 
 .. code-block:: bash
 
    -D ENABLE_COVERAGE=value  # enable coverage measurements, value = no (default) or yes
 
-This will also add the following targets to generate coverage reports after running the LAMMPS executable:
+This will also add the following targets to generate coverage reports
+after running the LAMMPS executable:
 
 .. code-block:: bash
 
@@ -100,7 +101,8 @@ This will also add the following targets to generate coverage reports after runn
    make gen_coverage_html  # generate coverage report in HTML format
    make gen_coverage_xml   # generate coverage report in XML format
 
-These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
+These reports require GCOVR to be installed. The easiest way to do this
+to install it via pip:
 
 .. code-block:: bash