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
