This keeps --disable-stylo working and --enable-stylo=build with the same
semantics, but it makes also --enable-stylo / and the default to not build the
old style system at all.
This also removes the stylo-only platforms, since they're now the default.
MozReview-Commit-ID: DL2eZZn9suE
We don't support Android for Gecko Profiler extension yet.
So for investigating arm issue, I would like to add initial support of
Gecko Profiler for Linux/arm.
--HG--
extra : rebase_source : f936a97a87b7eea2ebfefe3cbc7f8791bc90d03a
This commit adds a frontend construct, `GN_DIRS`, to facilitate building
gn projects with moz.build. Directories added to `GN_DIRS` get particular
treatment by two build backends added here as well, `GnConfigGen` and
`GnMozbuildWriter`.
The `GnConfigGen` backend runs `gn gen` for a gn project specified in
`GN_DIRS` and dumps this configuration as json, which is filtered to include
only those elements that will be needed by mozbuild. `gn gen` is run in
the context of a single build's configuration, so when adding or updating
a gn project it will be necessary to run this step with each supported
configuration.
The `GnMozbuildWriter` aggregates the config files generated by the
`GnConfigGen` backend, which it expects to find in the `gn-configs` directory
under the directory specified to `GN_DIRS`. The result is written to a set of
moz.build files suitable for building the project that are intended to be
checked in to the tree.
Once these moz.build files are checked in to the tree the project can be built
as any other directory: when using a general purpose build backend such as
RecursiveMake or FasterMake to build, entries in `GN_DIRS` will be treated as a
normal entries in `DIRS`.
MozReview-Commit-ID: KlHuP4DY2R4
--HG--
extra : rebase_source : b16079b3417bee3e58b0ecc8724b54c1b9d87d98
Revert the work-around from bug 1421635 now that the upstream
fix is applied.
MozReview-Commit-ID: GwmXr8zVBGn
--HG--
extra : rebase_source : 253428fac503e8820856b371e44aaa963e932e29
Work around crashes on win32 by disabling the decoder for
that target and 32-bit linux. Machines limited to 32 bits
are likely too slow for effective software playback anyway.
MozReview-Commit-ID: FP4wxP3FPOQ
--HG--
extra : rebase_source : 9bdd8a3719c21bb1d26af8272894cf7be46a02f4
All tests are passed with stylo, So let's turn on stylo even if Android.
MozReview-Commit-ID: X0ORZUn60a
--HG--
extra : rebase_source : 61f0d3513114a2d0716d9e660eba98004ff85bbf
All tests are passed with stylo, So let's turn on stylo even if Android.
MozReview-Commit-ID: X0ORZUn60a
--HG--
extra : rebase_source : f93f979711ab5f16eb3ced1d07e3c6d83464a6f0
This patch enables building of geckodriver in CI on Linux i686.
MozReview-Commit-ID: GkdHDJrzh2X
--HG--
extra : rebase_source : 3202702d8ae3423079aad512a3d7c8dc8e7408a3
This patch enables building of geckodriver in CI on Linux i686.
MozReview-Commit-ID: GkdHDJrzh2X
--HG--
extra : rebase_source : ab4588468939358a41d255dea3a01a8542e35a0e
This patch enables building of geckodriver in CI on Linux i686.
MozReview-Commit-ID: GkdHDJrzh2X
--HG--
extra : rebase_source : 2093fcecb9227852295377fe546b1ebe97d6459d
- Building is nightly channel only. Beta and release for Fennec 58 don't build
stylo. It means that the package size for 58 beta/release isn't incremented
by this change.
- The preference for stylo is still turned off Nightly 58. It will be turned on
59 after fixing some bugs for crashtests and etc. Our target to enable stylo
for Android is 59.
- ./mach bootstrap already installs clang etc to build stylo and bindgen.
Developers for mobile won't require additional build options for this change.
MozReview-Commit-ID: CIpYl8I5d7x
--HG--
extra : rebase_source : 6387704e4a94db080d4add10298cf1cc254ddec0
Stylo's recent enabled-by-default behavior, combined with some Linux
distributions's packaging of LLVM separately from Clang, causes
confusion. To allay such confusion, rearrange the configure checks to
do two things:
1) Check for the clang binary prior to checking for clang's shared
libraries; it should be more obvious what you need to install from
an error about clang, and installing clang should pull in the
necessary clang libraries, avoiding the following scenario:
- run configure
- get error message about libclang
- install libclang
- run configure
- get error message about clang
2) Provide some context for what to do to avoid this error; the user may
not understand why we need a separate C/C++ compiler when they already
have a perfectly suitable one on their system.
These were only enabled for b2g nightly builds, which we no longer
support, so these are unnecessary checks. The supporting code was
removed in bug 1396158.
MozReview-Commit-ID: 5oie28IlRz1
The `os` dereference here is only used in the error message,
and using it in the conditional tree doesn't really help
readability since it's too short; the target prefix is
helpful.
MozReview-Commit-ID: 4A8MpRH2r0p
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
Making more decisions on behalf of developers:
L10NBASEDIR is always defined, if not specified, it's ~/.mozbuild/l10n-central,
or in MOZBUILD_STATE_PATH/l10n-central if the state path in defined in the
environment.
If a locale isn't checked out, do that. The targets for which that works are
merge-%, installers-%, langpack-%
But only do that for Nightly builds, as for Beta and beyond, we have
explicit revisions to use for the builds, and we don't want to break release
builds silently with this.
MozReview-Commit-ID: EhGJPLuiyYO
--HG--
extra : rebase_source : 61a92396920965107a8811679552c1992b29155e
Build Stylo (the styling system from servo) by default in all
builds for win32, win64, macOS and linux64 targets. It was
previously enabled for automation builds, so this just changes
the behaviour for local developer builds.
Note that this introduces a new dependency on libclang for the
binding generator. If you're developing on a tier-1 platform,
run `./mach boostrap` to install a working copy. Otherwise
llvm+libclang 4.0.1 is recommended.
Remove the explicit --enable-stylo=build in mozconfig.stylo
in favour of the configure default.
Add mozconfig.stylo to the hazard and debug-asan mozconfigs
so LLVM_CONFIG is defined properly for those builds.
Based on a patch by Bobby Holly in bug 1356991.
MozReview-Commit-ID: C2wRNl7JHpz
--HG--
extra : rebase_source : 1ed7c36a64e25b235a26864592cd7ea969a4cd25
We've had trouble with crashes and hangs on macOS with
libclang builds from tooltool, so for local developer
builds we prefer the homebrew or macports packages
installed by `mach bootstrap`.
However, we were searching ~/.mozbuild before the homebrew
directory, resulting using the wrong libclang when developers
had run `mach bootstrap` before the switch, or anyone who
had used `mach artifact toolchain` on macOS.
MozReview-Commit-ID: JpLBDNthG6e
--HG--
extra : rebase_source : cca6f2772fd16425bd9b75cdfb4c7b60e4da577f
"value" here is a PositiveOptionValue, which behaves like a tuple.
Its __eq__ fails if the types of the operands aren't the same. A
string literal isn't a PositiveOptionValue, so the "value == 'build'"
check always fails. This meant that --enable-webrender=build was
always being interpreted as --enable-webrender. Yikes.
MozReview-Commit-ID: 57hWl0VqDmD
--HG--
extra : rebase_source : 44b858a4bbf9002813a16ba29429696005901ccc
Since Homebrew doesn't automatically place clang and associated binaries
on PATH, we need to do the task ourselves. MacPorts does place the
binaries in PATH, but uses yet another name, so we have to add that to
the search list.
Add the dependency between "MOZ_ENABLE_SKIA_PDF" and "MOZ_TREE_FREETYPE" on Windows:
- let |tree_freetype| returns true if |skia_pdf| returns true on Windows, and
- avoid defining "MOZ_ENABLE_CAIRO_FT" on Windows ("cairo-ft-font.c" includes <dlfcn.h>, which only exists on posix platforms)
MozReview-Commit-ID: 6CWVwzIHL1Q
llvm-config on Windows can return a path for the clang binary which does
not end in ".exe", which then causes failures when attempting to check
for the existence of the file. Rather than attempting to simply tack
".exe" onto the file if it's not already there, delegate to
moz.configure's `find_program` function, which will take care of that
case and several others besides.
The libclang test wants to find a libclang library for use for rust bindgen.
But that's a host process, that needs a host libclang. However, we
currently only have the target library/object prefix/suffixes. This
works fine... except when cross-compiling.
So we need to figure out the proper ones for the host, and use those
instead. For that, we templatize library_name_info in order to get a
separate set of library/object prefix/suffixes for the host and the
target.
And we use the host set for the libclang check.
Ideally, the build system would also use the host set for host tools
builds, but we'll leave that to a followup.
--HG--
extra : rebase_source : 1970791d6d5f9b3f79fbe34b7e3d05dd4b5c3f7b
The function as it currently is matches how things were done in
old-configure.in. However, that's just confusing and hard to follow. In
fact, the unit test failing numerous times while writing this patch
pretty much highlights the problem.
So instead of a confusing set of overrides to the prefixes and suffixes,
spell out the whole set for each set of platforms. This also happens to
make the function shorter. Win/win.
At the same time, we normalize the function output as a nested
namespace, where we get, for each of dll, lib, import_lib, etc. a
prefix/suffix pair. Further down the road, we can imagine changing those
to class instances with a method allowing to format file names based on
those prefix/suffixes.
--HG--
extra : rebase_source : c18520d4df54feeea0a7f9588bc3cf8346793aaf
Enable for Windows targets now that they're building.
MozReview-Commit-ID: HTitN5FKV7F
--HG--
extra : rebase_source : 06dbfbd99fe21ee6a14c9ece69c343172356a974
This option causes MOZ_USE_SYSTRACE to be defined. The only use of that is in
GeckoProfiler.h where it causes the PROFILER_PLATFORM_TRACING macro to set
android::ScopedTrace. But android::ScopedTrace was defined in widget/gonk/
which was recently removed, so this won't work any more.
Furthermore, all that android::ScopedTrace did was to do a pair of
atrace_{begin,end}() calls, which doesn't seem that useful.
For ease of use, we want to make checks for llvm-config automatically
examine the directory where `mach bootstrap` would install things, so
users don't necessarily have to have a mozconfig when building stylo.
Since the computation of this value is non-trivial, we pull out the
whole list of possible names for llvm-config into a @depends function,
and insert the computed value into that list when necessary.
It seems like when we get (lib)clang_path from a --with-(lib)clang-path option
it has type PositiveOptionValue. If we pass that directly to os.path.exists or
os.path.isdir we will get:
TypeError: coercing to Unicode: need string or buffer, PositiveOptionValue found
This patch makes us unwrap those values before passing them.
Ideally this check will alert people that something is wrong with their
configuration. This check shouldn't normally be firing with our `mach
boostrap` setup, but if somebody chooses to install distribution
packages for some reason, this will at least prevent some problems.
People building without a compilation environment (artifact builds, l10n
builds) won't have a compiler available, let alone the bits to build
bindgen. We should limit our checks for bindgen-y things accordingly.
Prior to this patch, we had a not-so-great hack in place: the bit of
configure that determined bindgen config paths *and* the bit of
configure that returned various pieces of information about Stylo were
both guarded on --enable-stylo-build-bindgen. We should really only
have one place that depends on --enable-stylo-build-bindgen, and this
patch puts us in a place to do that, by making bindgen_config_paths
properly use a when= argument to determine when it needs to run.
This commit makes the `stylo` function entirely redundant, and said
function will be removed in the next patch.
stylo.build is just a copy of stylo_config.build, so we should use the
former to limit the number of duplicate concepts we have. Using
stylo_config consistently enables us to separate out what artifact
builds need vs. non-artifact builds.
On some systems, llvm-config may be installed, but not the files to
which it needs to refer. We should ensure that the values returned
actually make some sense.
--with-libclang-path is supposed to be a directory, and
--with-clang-path is supposed to be a file, but it was easy to pass a
directory for the latter, and it was easy to misinterpret the
documentation for --with-libclang-path as pointing to one of the
libraries themselves. Clearer documentation and additional checks
should help with this situation.
The argument passed to the function is a PositiveOptionValue,
which represents its option values as a tuple. The __eq__ for
this type first compares type() of the operands. Since the
previous code compared a PositiveOptionValue to a string
literal, this always failed. There's possibly room to
improve the behavior of PositiveOptionValue. But for now,
let's rewrite stylo_config() so it works.
MozReview-Commit-ID: B4vkYwCDHrb
--HG--
extra : rebase_source : 639711bde7b96749405905825aae37a7908554a8
If we don't do this, various bits of test infrastructure will turn on
when stylo is merely built, not enabled, which will cause no end of
orange and unhappiness.
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
