☠☠ backed out by ce21e7a57cf8 ☠ ☠ | |
author | Gregory Szorc <gps@mozilla.com> |
Sun, 01 Mar 2015 22:15:07 -0800 | |
changeset 231293 | 3dac1282a10f39d89a7f8ff0c9cb3b52489cf934 |
parent 231292 | 002bca9bfb5540bee982b052f97c05a3d6bb6b0c |
child 231294 | 297f6188f37ccac6401e5dea1bbe165b03fedbb0 |
push id | 28348 |
push user | kwierso@gmail.com |
push date | Mon, 02 Mar 2015 20:13:43 +0000 |
treeherder | mozilla-central@abb7f0d180da [default view] [failures only] |
perfherder | [talos] [build metrics] [platform microbench] (compared to previous push) |
bugs | 1132771 |
milestone | 39.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
|
build/docs/files-metadata.rst | file | annotate | diff | comparison | revisions | |
build/docs/mozbuild-files.rst | file | annotate | diff | comparison | revisions |
--- 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``.