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.
We need to not build Widevine by default, and when enabled we will need to be able to
ifdef on MOZ_WIDEVINE_EME (see next patch) so that we can not build the code on platforms
where it can't possibly work (Android specifcally, as Widevine isn't available as a
Chromium plugin there).
MozReview-Commit-ID: Avgz5NRcl9v
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.
old-configure and js/src/old-configure interestingly didn't handle both
the same way. But vtune support is only actually implemented in js/src,
so only the rules from js/src/old-configure matter (nothing was
enforcing the decistion from old-configure to js/src/old-configure), and
this is what is implemented here.
Note the AC_DEFINE used to be in a COMPILE_ENVIRONMENT block, but the
define is actually used in Gecko preferences, so it's actually better
that the define is always set when MOZ_APPLEMEDIA is enabled.
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.
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.
