Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
We drop the check for MSVS_VERSION because it won't always be defined on
MinGW/GCC builds. We simply default to "2015" if it isn't set.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 302d76277058819c115f3c2518b8cb2067971950
extra : source : 408319d87eacb28848efeab0346eb815440adade
Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 1164621e00e2b917b5462d5ba310e0cc94d23bd9
At the same time, allow to enable jemalloc 4 with --enable-jemalloc=4.
MOZ_JEMALLOC4 will be deprecated later.
This also changes the semantics for freebsd, where the system jemalloc
is used, relying on MOZ_MEMORY being unset (default on freebsd) and
MOZ_JEMALLOC4 to be set. In this new setup, MOZ_JEMALLOC4 implies
--enable-jemalloc=4, which still works because of the corresponding
changes to old-configure.
While forgetting about it was warned about, having to add every new
environment option to wanted_mozconfig_variables is cumbersome. It turns
out there is a hackish way to make things work without that list, which,
all things considered, is not worse than the hacks around the
wanted_mozconfig_variables function, and are certainly an improvement as
it doesn't require an ever growing list of environment options.
For the same reasons as set_config is being moved to the global scope,
we're moving set_define to the global scope here. An additional change
is that set_define is now part of the sandbox itself instead of being
defined within the sandbox, which makes it share the implementation
details with set_config.
The way set_config is set currently makes it difficult to introspect
moz.configure files to know what configuration items are being set,
because they're hidden in the control flow of functions.
This makes some of the moz.configure more convoluted, but this is why
there are templates, and we can improve the recurring cases afterwards.
This change adds a `Version` type to moz.configure which is a small
wrapper around `distutils.version.Version`. It's suitable for wrapping
version numbers in configure checks and doing equality or greater-than
less-than comparisons in a sensible way.
MozReview-Commit-ID: BOL6yvemulG
--HG--
extra : rebase_source : 3b463eac0499086f8acffda0d01418b6ab17f3d6
extra : amend_source : aebd6e40c408d9f868623b2f53fcdf7455e2fff5
This aligns with the triplets used by clang/llvm. Technically, this
won't break iOS builds still using -darwin triplets until we move
MOZ_IOS_SDK to moz.configure and actively reject non iOS targets with
the iOS sdk.
Also allow to distinguish iOS and OSX with target.os.
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.
Gregory Szorc
Wes Kocher
Chris Manchester
Ms2ger
Mike Hommey
Ted Mielczarek