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
Subtly, as toolkit/moz.configure happens before toolchain tests, we
can't set MOZ_SERVO_LIBS from there. And toolkit/moz.configure is
not always included either, making things awkward to do in python
configure.
OTOH, there's only one place where MOZ_SERVO_LIBS is used, and the
corresponding setup can actually be done there (in moz.build) instead.
I think we shouldn't shy away from moving things this way.
Gpsd is the GPS daemon on Linux. It implements support for a wide range
of GPS receivers. This patch adds support for gpsd to the Geolocation
module.
The build system can now test for libgps, which provides the public
interface to gpsd's functionality. If found, |GpsdLocationProvider|
is added to the build.
MozReview-Commit-ID: 1kBgFdEZePI
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
