Because some of the existing mozconfigs may be setting some variables,
we need to inject those that are handled by moz.configure now. It likely
doesn't matter for the variables currently in moz.configure, but it will
soon become important when more things are moved to moz.configure.
In fact, it is necessary for GENISOIMAGE and DSYMUTIL that we're going
to move in this bug, set in automation mozconfigs.
The implementation is cumbersome and quite horrible. We could do better
by changing the execution model in mozbuild.configure, which is probably
necessary for other reasons as well, but that requires more work and
testing.
It's an opt-in flag that allows to display where the build is in
terminal window titles. The fact that it's opt-in and likely unknown
makes it very low-value, and the fact that it was added in an era where
builds were not very well parallelized made it have a meaning, but now
that builds are parallelized, its meaningfulness is diminished.
Let's just remove it.
With all the things that still depend on all the variables derived from
--host and --target in both old-configure and moz.build, we still need
to keep variables such as OS_ARCH, OS_TARGET, CPU_ARCH, OS_TEST, etc.
Eventually, we'd settle on the output of split_triplet.
This /tries/ to preserve the current values for all these variables,
while also trying to make things a little more consistent. It also
effectively rejects OSes such as HPUX or AIX, because it is unclear
the decades old accumulated scripts related to them still do anything
useful, and we might as well have them start again from scratch, which,
in the coming weeks, will be even easier.
The data we get out of mozconfig can be unicode, and needs to be in a
form the shell used to run old-configure will be able to recognize,
which is likely utf-8 on UNIX (that's what we settled on), and mbcs on
Windows.
So far, we've been passing down all configure_args from mozconfig as
well as every flag appearing on sys.argv. This is overly broad and
causes problems for some options, like --enable-application.
However, we don't need all these options to be passed.
For the top-level old-configure, we need to pass the flags it can
handle, as well as the flags that we want passed down to
js/src/configure.
For js/src/old-configure, we only need to pass the flags it can handle.
The flags an old-configure can handle is defined by the list of flags
in @old_configure_options. The list of flags to pass down to
js/src/configure is defined by extra_old_configure_args.
And since the mozconfig configure_args are being injected into python
configure processing, the list of values we get in old_configure includes
the mozconfig configure_args.
While the long term goal is that js and top-level use the same configure
and the same overall setup, including the possibility to use mozconfigs,
figuring out what we want to do wrt mozconfig vs. command line and
environment variable is not a clear-cut case, and it's more important to
fix the immediate problem mozconfig causes to js developers by
"temporarily" returning to the previous behavior of not loading the
mozconfig for the js configure.
This was already done in the case of running it as a subconfigure, this
extends the exception. Unfortunately, there is no direct way to tell
whether the running configure is the js configure. The indirect way is
to look at the OLD_CONFIGURE path, which points to
js/src/old-configure.
I expect we'll have figured things out for mozconfigs well before
old-configure dies.
The implementation is a bit circumvoluted, but we do need to share
options between the top-level and js/src configures, possibly with
different defaults, and to properly pass things down from one to
the other. Until we are further down the road and can actually merge
both configures, this is a necessary evil.
This spins up a separate process to submit telemetry data rather than
blocking the execution the current mach command.
Although the initial Python process needs to wait for the second process
to complete prior to exiting, it releases control of the console once it
finishes executing Python code, so from the user's perspective, mahc command
completion is not blocked by submitting telemetry data.
MozReview-Commit-ID: FlKDYd6rNPc
--HG--
extra : rebase_source : d10f3f2cdfe6e8c8cdd8b1e02ce9261178b528e6
Because --enable-application is the current way to do things, transpose
it to configure.py, but since --enable-application=js doesn't make
sense, make it an alias of a new --enable-project option.
This only partially moves --enable-application out of old-configure.in
because there are a lot of other things intertwined with it.
This moves all the reading mozconfig, finding autoconf, refreshing the
old configure, and running the old configure into sandboxed
moz.configure. This effectively bootstraps the sandboxed python configure.
The nice side effect is that now we can have actual dicts for defines
and substs from the start, which simplifies so things, although it
requires adjustments to some unit tests.
