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.
As a first step, this moves PYTHON_UNIT_TESTS to moz.build as a passthru
variable. In the future, we could hook it up to |mach test|.
The __init__.py files may not need to be in the list, but I don't want to
change the list here.
While I was here, I removed the try..except in favor of failing fast.
Before, we were only making cosmetic changes. Now, we actually need the
group for mach to work. It makes sense to stop ignoring errors.
This fixes a regression from d53d1c6cdf13 / bug 951733.
--HG--
extra : rebase_source : aeb6c99a945eaff32cf86fa481d03c0c8dee593a
extra : amend_source : f1e29385bf8ca8ac250a04f81e7e955c4152b476
Some moz.build syntax errors cause the thrown SyntaxError object to not include
an offset field, leading to all sorts of hilarity when we try printing messages
depending on SyntaxError.offset. Check for this case and simply don't print
the caret if so.
We want to make it turnkey for people to use reviewboard. So, we add
reviewboard and related functionality to |mach mercurial-setup|.
Since the reviewboard extension only works in Mercurial 3.0 and newer,
we add some version detection for the Mercurial version. This should
have been done months ago. We now have it.
I also took the opportunity to inform |mach bootstrap| that Mercurial
2.x is no longer modern.
I also updated the messaging around mq to encourage fewer new users to
use it. You may find this controversial. People can always ignore the
message.
Finally, I also added a histedit prompt to the mix, since a lot of
people don't know about that and many find it useful.
I could have broken this into multiple patches. Meh.
--HG--
extra : rebase_source : d33f8abcabb6ad6511c2f9e202283d43613fafc4
extra : amend_source : 3a56bc4d49ee6200cbdd0e87b4f28489518fee79
This adds a format option to mach environment and uses it in client.mk to
create a .mozconfig.json in the objdir, containing all the relevant data
from mozconfig. If the mozconfig doesn't change in a way that alters that
data, we still skip configure.
At the same time, use mach environment in place of mozconfig2configure and
mozconfig2client-mk, which makes us now have only one mozconfig reader.
Also, in the mozconfig reader, keep track of environment variables (as
opposed to shell variables), so that changes such as a variable that was
exported not being exported anymore is spotted. At the opposite, in order
for irrelevant environment variable changes not to incur in re-running
configure, only a set of environment variables are stored when they are
unmodified. Otherwise, changes such as using a different terminal window,
or even rebooting, would trigger reconfigures.
Finally, make mach environment emit both MOZ_OBJDIR and OBJDIR for
client.mk, and cleanup some objdir-related things in client.mk..
At the same time, make the mozconfig reader take MOZ_OBJDIR from the
environment if it is defined there and not in the mozconfig.
