This adds back a MOZ_ENABLE_WEBRENDER define, which only controls whether or
not WebRender is enabled at runtime. The default behaviour is changed so that:
- if the user specifies --disable-webrender in the mozconfig, WebRender is
neither built nor enabled
- if the user specifies --enable-webrender in the mozconfig, WebRender is
built and enabled
- if the user specifies --enable-webrender=build in the mozconfig, WebRender is
built but not enabled, except on Android where it is neither built nor enabled
- if the user doesn't specify any of the above, the default behaviour is:
- on nightly/local builds, the same as --enable-webrender=build
- on other channels (e.g. aurora), the same as --disable-webrender
The net effect is that local/Nightly-automation builds will have WebRender
built-in but not enabled where possible (i.e. not Android). However the user
can override this behaviour via mozconfig options to either not build WebRender
at all, or to enable it in addition to building it.
MozReview-Commit-ID: IM7DdSHkIB
This patch tries to do three things:
1) Replace the ENABLE_MARIONETTE entrypoint with --enable-marionette.
2) Fold the default value -- forced on unless building for target OS
Android or building with toolkit gonk -- into the flag, rather than
embedding that condition in the tree.
3) Stop using AC_DEFINE and instead use only AC_SUBST, so that no
compiled code needs to be rebuilt if the flag is flipped locally.
n.b., each installer/Makefile.in knows that ENABLE_MARIONETTE is set
(in order to set -DENABLE_MARIONETTE=1 for
*/installer/package-manifest.in) due to it being an AC_SUBST.
MozReview-Commit-ID: AkkmybyP1uI
--HG--
extra : rebase_source : c2c8b268c60350ff39d872cee357b53f17e79eef
Spidermonkey doesn't currently depend on rust code, and this
unblocks enabling rust by default on gecko builds until we
can get the appropriate toolchain hooked up to all of the
SM automation jobs.
The include must be conditional to avoid breaking artifact builds.
MozReview-Commit-ID: 1PmcFvcZLM2
--HG--
extra : rebase_source : 1a22232e064dd253b80ebaa55decfde1ba7e1ea0
Before, --enable-dmd implied --enable-jemalloc. If --enable-stylo was
also set, it tried to imply --enable-jemalloc=moz. Configure barfed
due to setting the value twice.
The commit refactors the logic for implying the --enable-jemalloc value
to set the proper value depending on the state of dmd and stylo.
MozReview-Commit-ID: 1wKE9Cs1Umt
--HG--
extra : rebase_source : 03acfc386fa9c86ae90e0feb5dae092ea5897179
Previously, we recorded it in defines. Let's add it in substs so more
tools can key off it.
MozReview-Commit-ID: HDrf46BCd6W
--HG--
extra : rebase_source : be8cae71dfbe994fa6dadbdb0007e430413c743b
extra : source : 9e707fcf47691a4684d7b6953dd8a08ae6687893
Importing 'os' in python configure functions, on Windows, changes the
separate the various os.path functions use, and that can have
unexpected, badly handled, consequences. While on the long term, it is
desirable to make @imports('os') modify os.path to use the same base
functions as if there were no @imports, let's go with the simpler
workaround of restoring the non-{isfile,isdir,exists} os.path functions
from b6be0e9e3e1e.
--HG--
extra : rebase_source : a1857b5dce2aa818c72a77d0d9727ac6ce16cb8f
We want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a
On FreeBSD the target.kernel etc checks in enable_eme are failing,
but we're still falling through to |return value|, and so Widevine
is being enabled. If we remove the |return value| from enable_eme
we at least make Widevine disabled where it's not supposed to be
enabled.
MozReview-Commit-ID: D1h0IUidxhv
--HG--
extra : rebase_source : 10696291b91d79d4971932796cab4494c88eca3b
extra : amend_source : ccb0a165f5deb0a8ae60256fb97b5d972e42bf28