Merge pull request #60 from kirkrudolph/master

Grammar and typo changes

docs/overview/cmake-can-not.rst

@@ -34,7 +34,7 @@ XML files, autotools configs or `JSON-like syntax`_.
 
 Think about it in this
 way: if you want to do some nasty non-standard thing then probably you should
-stop.  If you think it is something important and useful, then it might be
+stop.  If you think it is something important, then it might be
 quite useful for other :ref:`CMake <CMake>` users too. In this case you need to
 think about implementing new feature **in CMake itself**.  :ref:`CMake <CMake>`
 is open-source project written in C++, and additional features are always being introduced.

docs/overview/cmake-can.rst

@@ -38,9 +38,9 @@ approach is error prone and not flexible.
 
 .. _cmake generate native build tool:
 
-CMake solve this design flaw by adding extra step to development process. You
-can describe your project in ``CMakeLists.txt`` file and use :ref:`CMake <CMake>` to
-generate tools you currently interested in using cross-platform :ref:`CMake <CMake>` code:
+CMake solve this design flaw by adding an extra step to the development process. You
+can describe your project in a ``CMakeLists.txt`` file and use :ref:`CMake <CMake>` to
+generate the cross-platform build tools:
 
 .. image:: /overview/images/generate-native-files.png
   :align: center
@@ -66,11 +66,11 @@ keep using your favorite tools like ``Visual Studio/msbuild``,
 VCS friendly
 ============
 
-When you work in team on your code you probably want to share and save the
-history of changes, that's what usually :ref:`VCS <VCS>` used for. How does
-storing of IDE files like ``*.sln`` works on practice? Here is the diff after
-adding ``bar`` executable with ``bar.cpp`` source file to the ``Visual Studio``
-solution:
+Version Control (:ref:`VCS <VCS>`) is used to share and save your code's
+history of changes when you work in a team. However, different IDEs use unique
+files to track project files (``*.sln``, ``*.pbxproj``, ``*.vscode``, etc)
+For example, here is the diff after adding ``bar.cpp`` source file to the ``bar`` 
+executable in ``Visual Studio``:
 
 .. literalinclude:: /overview/snippets/foo-new.sln
   :diff: /overview/snippets/foo-old.sln
@@ -98,9 +98,8 @@ When using ``Xcode``:
 .. literalinclude:: /overview/snippets/project-new.pbxproj
   :diff: /overview/snippets/project-old.pbxproj
 
-As you can see there are a lot of magic happens while doing quite simple
-task like adding new target with one source file. Looking at the diffs above
-try to answer next questions:
+As you can see, a lot of magic happens while doing a simple
+task like adding one new source file to a target. Aditionaly,
 
 * Are you sure that all XML sections added on purpose and was not the result
   of accidental clicking?
@@ -126,7 +125,7 @@ Experimenting
 =============
 
 Even if your team has no plans to work with some :ref:`native tools <Native build tool>`
-originally this may change in future. E.g. you have worked with ``Makefile`` and
+originally, this may change in the future. E.g. you have worked with ``Makefile`` and
 want to try ``Ninja``. What you will do? Convert manually? Find the converter?
 Write converter from scratch? Write new ``Ninja`` configuration from scratch?
 With :ref:`CMake <CMake>` you can change ``cmake -G 'Unix Makefiles'`` to

docs/tutorials/version-policies.rst

@@ -72,8 +72,8 @@ versions of CMake then you need to put the smallest one in
 
 .. _cmake_minimum_required should be first:
 
-Even if some commands look harmless at the first glance it may be not so
-in fact, e.g. ``project`` is the place where a lot of checks happens and where
+Even if some commands look harmless, they might not be. For example, ``project``
+is the place where a lot of checks happens and where the
 toolchain is loaded. If you run this example on ``Cygwin`` platform:
 
 .. literalinclude:: /examples/minimum-required-example/bad/CMakeLists.txt
@@ -156,12 +156,12 @@ CMake policies
 
  * `CMake policies <https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html>`__
 
-When new version of CMake released there may be a list of policies describing
+When a new version of CMake is released, there may be a list of policies describing
 cases when behavior changed comparing to the previous CMake version.
 
-Let's see how it works on practice. In CMake ``3.0`` policy
+Let's see how it works in practice. In CMake ``3.0`` policy
 `CMP0038 <https://cmake.org/cmake/help/latest/policy/CMP0038.html>`__
-was introduced. Before version ``3.0`` user can have target linked to itself,
+was introduced. Before version ``3.0``, a target could be linked to itself,
 which make no sense and definitely **is a bug**:
 
 .. literalinclude:: /examples/policy-examples/bug-2.8/CMakeLists.txt
@@ -218,7 +218,7 @@ For CMake version ``>= 3.0`` warning will be reported:
   -- Generating done
   -- Build files have been written to: /.../policy-examples/_builds
 
-Assume you want to drop the support of old version and more to some new
+Assume you want to drop support for the old version and more to some new
 ``3.0`` features. When you set ``cmake_minimum_required(VERSION 3.0)``
 
 .. literalinclude:: /examples/policy-examples/set-3.0/CMakeLists.txt
@@ -255,11 +255,11 @@ warning turns into error:
   [policy-examples]> echo $?
   1
 
-Two cases will be shown below. In first case we want to keep support of old
-version (``2.8`` for now) so it will work with both ``CMake 2.8`` and
-``CMake 3.0+``. In second case we decide to drop support of old version and move
-to ``CMake 3.0+``. We'll see how it will affect policies. It will be shown in
-the end that in fact without **using new features** from ``CMake 3.0`` it
+Two cases will be shown below. In the first case we want to keep support of
+version ``2.8`` so it will work with both ``CMake 2.8`` and
+``CMake 3.0+``. In the second case we decide to drop support of version ``2.8`` and move
+to ``CMake 3.0+``. We'll see how it affects the policies. It will be shown
+that without **using new features** from ``CMake 3.0``, it
 doesn't make sense to change ``cmake_minimum_required``.
 
 Keep using old
@@ -357,8 +357,8 @@ Final version:
 Moving to new version
 ~~~~~~~~~~~~~~~~~~~~~
 
-With ``cmake_minimum_required`` updated to ``3.0`` warning turns into error.
-To suppress error without doing real fix (temporary solution) you can add
+With ``cmake_minimum_required`` updated to ``3.0``, the warning turns into an error.
+As a temporary solutuion, the error can be suppressed by adding a
 ``cmake_policy`` directive:
 
 .. literalinclude:: /examples/policy-examples/suppress-3.0/CMakeLists.txt
@@ -371,7 +371,7 @@ To suppress error without doing real fix (temporary solution) you can add
   condition since ``cmake_minimum_required(VERSION 3.0)`` guarantee us that
   we are using ``CMake 3.0+``.
 
-Policy can be removed after real fix applied:
+This policy can then be removed once a better solution is found:
 
 .. literalinclude:: /examples/policy-examples/fix-3.0/CMakeLists.txt
   :diff: /examples/policy-examples/suppress-3.0/CMakeLists.txt

docs/tutorials/workflow.rst

@@ -9,7 +9,7 @@ developer's workflow: The :ref:`native build tool <native build tool>` will watc
 the CMake sources for changes and re-run the configure step automatically. In
 command-line terms it means that you have to run ``cmake -H. -B_builds`` **only
 once**, you don't need to run configure again after modification of
-CMakeLists.txt - you can keep using simply ``cmake --build``.
+CMakeLists.txt - you can simply use ``cmake --build``.
 
 Makefile example
 ================