The install manifest processor starts with an empty InstallManifest and
uses |= to "concatenate" instances. It became pretty obvious when
developing some patches that add more preprocessed files to install
manifests that the source install manifest dependency was getting
lost during the |= operation. This patch fixes it.
The solution is not ideal performance wise. But slightly worse
performance (only after config.status, however) is better than
clobbers.
A test has been added to ensure this doesn't regress.
--HG--
extra : rebase_source : 848aebbbc935ce2bca2d3fcc85d1df534e734e0d
- parent and var were used for TOOL_DIRS/TEST_TOOL_DIRS, which were removed in
bug 1043802.
- tier metadata was not really used, and tiers are going to go away soon
anyways.
As handled in configure.in, EXTERNAL_SOURCE_DIR is a single directory for
external sources, and more specifically, comm-central. There is no need
to handle it as a list in the moz.build emitter.
At the same time, avoid checking the external sources for every moz.build,
and bind it to a config environment.
As a special exception, we change List's + and += operators to treat
"+ None" and "+= None" as "+ []" and "+= []" respectively.
This is a hack to make moz.build files simpler so they don't have to
perform "is x" checks before appending x.
While I was here, I fixed the implementation of List.__add__ to return a
List instead of list.
--HG--
extra : rebase_source : e61db4be4cf8144b092609d3baf84c372b9cf9a0
extra : amend_source : dfabc00765582764426f7cf74e79354a0bfb0824
This change merges mozilla-central and comm-central into having a single
topobjdir file but retaining two topsrcdirs (and two build systems). This state
is hopefully only the first part of a series of changes that eliminate the
comm-central build system partial clone completely.
--HG--
extra : rebase_source : 02aa2c4551df405d9783ac85cc41fe90b67bf057
extra : amend_source : d3cc677d59603648165bf65afa28413f2c40b2fd
This patch add a line at the end of the build like follows:
ccache (direct) hit rate: 98.7%; (preprocessed) hit rate: 0.5%; miss rate: 0.8%
--HG--
extra : rebase_source : 9c814745516d7b8b0db2056a1fa0df540a5a239a
This patch makes EXTRA_{PP_,}JS_MODULES similar in functionality to
TESTING_JS_MODULES: we indicate the path relative to
$(FINAL_TARGET)/modules with an appropriate hierarchy of paths.
We're going to build on top of INSTALL_TARGETS for the next patch, and
it's easiest to do so if we can look at the 'directories' in the
hierarchy, rather than the individual strings.
I am slightly surprised that we haven't needed this before, but the
motivating idea behind this is wanting to do:
VARIABLE.with.some["non-pythonic-identifier"] += ...
It seems unfortunate that the behavior is completely overridden by
subclasses, but I don't see a good way around that.
Straight assignments to HierarchicalStringList, which we'll change
EXTRA_JS_MODULES to in a later patch, don't work. This change, in
addition to making things work as expected later on, also is more
consistent with existing practice.
While most environments are using the root topobjdir, some can be using a
different path. This happens for comm-central files. For those, the compile
target needs to have paths relative to the root topobjdir instead of relative
to the comm-central topobjdir.
