Enable av1 decoding with the aom reference library on nightly
build except on Windows and Android where it's not working yet.
This codec is under development and subject to incompatible
changes. We're supporting a specific encoder revision for
testing with website authors to get early feedback.
See media/libaom/README_MOZILLA for the specific codec commit
hash our decoder expects.
MozReview-Commit-ID: JCPiVFg3geC
--HG--
extra : rebase_source : c7b9de67415d885ada64658f8f938b4091b468e3
geckodriver compilation was disabled by default in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368084 due to issues
building it locally on Windows.
This re-enables building of geckodriver in automation, but gives
developers an option, --enable-geckodriver, to opt-in to building
it locally.
geckodriver is implied on supported platforms when MOZ_AUTOMATION is
set, but we also provide the option for developers to use. This means
geckodriver will be built in CI by default, but not in developers'
local environments.
MozReview-Commit-ID: ACkO97ekVsi
--HG--
extra : rebase_source : 067e25911f72d80a54e662f24cc71dedde53a4e1
This is the equivalent of MOZ_INSTALL_TRACKING, but for MMA (Mobile
Marketing Automation) using the Leanplum SDK.
To test this locally, add lines like:
export MOZ_ANDROID_MMA=1
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk-developer.token
MOZ_ANDROID_MMA depends on MOZ_NATIVE_DEVICES and MOZ_ANDROID_GCM,
since Leanplum requires Google Play Services library that those flags
are a proxy for and enable, respectiviely.
We want to enable MOZ_ANDROID_MMA in Nightly, but only for
MOZILLA_OFFICIAL builds. Since MOZILLA_OFFICIAL is still defined in
old-configure.in, we can't interrogate it in
mobile/android/moz.configure, and therefore we enable using the
automation mozconfigs.
MozReview-Commit-ID: 1tiToeyH5Hx
--HG--
extra : rebase_source : f85706c5a0911c7d2edc109d8c47ecc1c1bc6ffc
This is the equivalent of MOZ_INSTALL_TRACKING, but for MMA (Mobile
Marketing Automation) using the Leanplum SDK.
To test this locally, add lines like:
export MOZ_ANDROID_MMA=1
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk-developer.token
MOZ_ANDROID_MMA depends on MOZ_NATIVE_DEVICES and MOZ_ANDROID_GCM,
since Leanplum requires Google Play Services library that those flags
are a proxy for and enable, respectiviely.
We want to enable MOZ_ANDROID_MMA in Nightly, but only for
MOZILLA_OFFICIAL builds. Since MOZILLA_OFFICIAL is still defined in
old-configure.in, we can't interrogate it in
mobile/android/moz.configure, and therefore we enable using the
automation mozconfigs.
MozReview-Commit-ID: 1tiToeyH5Hx
--HG--
extra : rebase_source : 5390cf8c5c2eb7ffe675757b372debbb639bc900
Reword the `llvm-config` detection error message to recommend setting the
LLVM_CONFIG env var, like we do for the bootstrap path. This avoids exposing
`clang` as well, so the compiler won't be changed.
MozReview-Commit-ID: CVNJ2bX2POa
--HG--
extra : rebase_source : fedfb95e105f88fec08689ae3c69a841f3b52173
Build system switch for optional inclusion of libaom
for support of the Alliance for Open Media AV1 video
codec.
MozReview-Commit-ID: 2C4o1ogRS9v
--HG--
extra : rebase_source : d4a68f1fc4654895f62a905666f0b75726e20e7f
llvm39 package on FreeBSD installs llvm-config under non-default
prefix with llvm-config39 wrapper under PATH. No package currently
provides default/unsuffixed llvm-config. So, adjust lookup to avoid
having to add "export LLVM_CONFIG=llvm-config39" in .mozconfig for the
common case when Stylo bindgen is known to work.
MozReview-Commit-ID: 9PmnpTPoBcR
--HG--
extra : rebase_source : 6c252e9e0e8da1f02fa74107597f69066b024f55
bindgen, for whatever reason, is much happier with C:/path/to/file
than "normal" Windows paths. If we provide normal Windows paths,
clang-sys will complain that it's unable to find libclang.dll/clang.dll,
even though we've clearly given it the correct paths by passing in an
appropriate value for LIBCLANG_PATH.
We'll want to define LLVM_CONFIG in mozconfig.common for building Stylo
by default. But if we do that, builds where we don't have an
appropriate clang available will complain that they can't find
llvm-config. So we should only check if we're building Stylo.
We currently have an --enable-stylo option, which when passed builds
Stylo and enables Stylo at runtime. With an upcoming move to building
Stylo everywhere by default, but only enabling it on specific platforms,
we need something more sophisticated than a binary yes/no.
The recent WebRender support offers a model worth emulating: we modify
things so there are four possibilities:
* nothing passed (the default);
* --disable-stylo (explicitly not building);
* --enable-stylo=build (build, but do not enable by default);
* --enable-stylo (build and enable)
The last option corresponds exactly to what we have today, so there's no
change in functionality. This patch makes the default and
--disable-stylo the same; splitting the default and --disable-stylo into
separate cases enables us to change the default behavior at some point
in the future.
Released versions of LLVM 4.0 do not work properly with bindgen, and the
in-development 5.0 version doesn't either. To avoid undue hair-pulling,
we should detect such versions early during configure and advise the
user about appropriate versions.
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
This compile time option only allows to explicitly enable/disable
build of Wayland related parts of Firefox.
We target Gtk/Wayland in stable Gtk+ 3.22 and later.
MozReview-Commit-ID: LfQfEkYfHf8
--HG--
extra : rebase_source : 9ac5ad3b2ef0efdae052388c8c6d30c99d044996
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
Henri Sivonen
Ralph Giles
Andreas Tolfsen
Nick Alexander
Sebastian Hengst
Andrew Swan
Ryan VanderMeulen
Mike Hommey
J. Ryan Stinnett
Emilio Cobos Álvarez
Wes Kocher
Ted Mielczarek
Jan Beich
Kit Cambridge
Jim Chen
Nathan Froyd
Bobby Holley
Martin Stransky
Kartikaya Gupta
Sotaro Ikeda
Matt Brubeck
Christoph Diehl
Nicholas Nethercote
Carsten "Tomcat" Book
Christian Holler
nfroyd@mozilla.com
Chris Pearce
Jonathan Kew
Lee Salzman
Jonathan Watt
lochang
Gregory Szorc
Chris Manchester
Michelangelo De Simone
James Cheng
Bobby Holley