Bug 1132771 - Fix grammar nits in moz.build documentation
☠☠ backed out by ce21e7a57cf8 ☠ ☠
authorGregory Szorc <gps@mozilla.com>
Sun, 01 Mar 2015 22:15:07 -0800
changeset 231293 3dac1282a10f39d89a7f8ff0c9cb3b52489cf934
parent 231292 002bca9bfb5540bee982b052f97c05a3d6bb6b0c
child 231294 297f6188f37ccac6401e5dea1bbe165b03fedbb0
push id28348
push userkwierso@gmail.com
push dateMon, 02 Mar 2015 20:13:43 +0000
treeherdermozilla-central@abb7f0d180da [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1132771
milestone39.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1132771 - Fix grammar nits in moz.build documentation These were left over from a Ms2ger review and weren't seen before landing. DONTBUILD (NPOTB)
build/docs/files-metadata.rst
build/docs/mozbuild-files.rst
--- a/build/docs/files-metadata.rst
+++ b/build/docs/files-metadata.rst
@@ -7,17 +7,17 @@ Files Metadata
 :ref:`mozbuild-files` provide a mechanism for attaching metadata to
 files. Essentially, you define some flags to set on a file or file
 pattern. Later, some tool or process queries for metadata attached to a
 file of interest and it does something intelligent with that data.
 
 Defining Metadata
 =================
 
-Files metadata is defined by utilizing the
+Files metadata is defined by using the
 :ref:`Files Sub-Context <mozbuild_subcontext_Files>` in ``moz.build``
 files. e.g.::
 
     with Files('**/Makefile.in'):
         BUG_COMPONENT = ('Core', 'Build Config')
 
 This working example says, *for all Makefile.in files in all directories
 in this one and underneath it, set the Bugzilla component to
--- a/build/docs/mozbuild-files.rst
+++ b/build/docs/mozbuild-files.rst
@@ -67,20 +67,20 @@ to an empty sandbox are all defined in t
 This module also contains documentation for each symbol, so nothing can
 sneak into the sandbox without being explicitly defined and documented.
 
 Reading and Traversing moz.build Files
 ======================================
 
 The process for reading ``moz.build`` files roughly consists of:
 
-1. Start at the root ``moz.build`` (``<topsrcdir>/moz.build``)
-2. Evaluate the ``moz.build`` file in a new sandbox
+1. Start at the root ``moz.build`` (``<topsrcdir>/moz.build``).
+2. Evaluate the ``moz.build`` file in a new sandbox.
 3. Emit the main *context* and any *sub-contexts* from the executed
-   sandbox
+   sandbox.
 4. Extract a set of ``moz.build`` files to execute next.
 5. For each additional ``moz.build`` file, goto #2 and repeat until all
    referenced files have executed.
 
 From the perspective of the consumer, the output of reading is a stream
 of :py:class:`mozbuild.frontend.reader.context.Context` instances. Each
 ``Context`` defines a particular aspect of data. Consumers iterate over
 these objects and do something with the data inside. Each object is
@@ -113,25 +113,25 @@ directory, ``foo``, you would add ``DIRS
 file and ``foo/moz.build`` would be evaluated.
 
 .. _mozbuild_fs_reading_mode:
 
 Filesystem Reading Mode
 -----------------------
 
 There is an alternative reading mode that doesn't involve the build
-system and doesn't utilize ``DIRS`` variables to control traversal into
+system and doesn't use ``DIRS`` variables to control traversal into
 child directories. This mode is called *filesystem reading mode*.
 
 In this reading mode, the ``CONFIG`` variable is a dummy, mostly empty
 object. Accessing all but a few special variables will return an empty
 value. This means that nearly all ``if CONFIG['FOO']:`` branches will
 not be taken.
 
-Instead of utilizing content from within the evaluated ``moz.build``
+Instead of using content from within the evaluated ``moz.build``
 file to drive traversal into subsequent ``moz.build`` files, the set
 of files to evaluate is controlled by the thing doing the reading.
 
 A single ``moz.build`` file is not guaranteed to be executable in
 isolation. Instead, we must evaluate all *parent* ``moz.build`` files
 first. For example, in order to evaluate ``/foo/moz.build``, one must
 execute ``/moz.build`` and have its state influence the execution of
 ``/foo/moz.build``.