We can't yet enable the build by default since it pulls in networking functions
into libgkrust which runs afoul of the checks added in bug 1376621.
Differential Revision: https://phabricator.services.mozilla.com/D28353
--HG--
extra : moz-landing-system : lando
The previous commit disabled the remote agent by flipping the
remote.enabled preference to false. That prevented the remote
agent from initialising or being included in the --help message.
This patch implies --enable-cdp in the default Firefox build on Firefox
Nightly. Firefox for Android is not supported. This will cause
builds to include the remote agent component that lives under remote/.
Since the remote agent is disabled by default, users will first
have to set the remote.enabled preference to true in order to use it.
If you wish to explicitly opt out of including the remote agent
when building Firefox, you may do so by using the --disable-cdp
build flag in your mozconfig:
ac_add_options --disable-cdp
Differential Revision: https://phabricator.services.mozilla.com/D27540
--HG--
extra : moz-landing-system : lando
The previous commit disabled the remote agent by flipping the
remote.enabled preference to false. That prevented the remote
agent from initialising or being included in the --help message.
This patch implies --enable-cdp in the default Firefox build on Firefox
Nightly. Firefox for Android is not supported. This will cause
builds to include the remote agent component that lives under remote/.
Since the remote agent is disabled by default, users will first
have to set the remote.enabled preference to true in order to use it.
If you wish to explicitly opt out of including the remote agent
when building Firefox, you may do so by using the --disable-cdp
build flag in your mozconfig:
ac_add_options --disable-cdp
Differential Revision: https://phabricator.services.mozilla.com/D27540
--HG--
extra : moz-landing-system : lando
Changes --enable-verify-mar to be the default. Builds that want to disable mar verification will need to specify --disabled-verify-mar.
Removes --enable-verify-mar from Firefox's mozconfigs since it is no longer needed.
Re-enables app update browser chrome tests on ASAN that were disabled due to the ASAN mozconfigs not specifying --enable-verify-mar.
This also makes the same app update browser chrome tests on code coverage builds due to the code coverage mozconfigs not specifying --enable-verify-mar.
Differential Revision: https://phabricator.services.mozilla.com/D28288
--HG--
extra : moz-landing-system : lando
The previous commit disabled the remote agent by flipping the
remote.enabled preference to false. That prevented the remote
agent from initialising or being included in the --help message.
This patch implies --enable-cdp in the default Firefox build on Firefox
Nightly. Firefox for Android is not supported. This will cause
builds to include the remote agent component that lives under remote/.
Since the remote agent is disabled by default, users will first
have to set the remote.enabled preference to true in order to use it.
If you wish to explicitly opt out of including the remote agent
when building Firefox, you may do so by using the --disable-cdp
build flag in your mozconfig:
ac_add_options --disable-cdp
Differential Revision: https://phabricator.services.mozilla.com/D27540
--HG--
extra : moz-landing-system : lando
In particular, this enables Marionette in local Fennec builds, which
were the only place it wasn't enabled by default. (Automation builds
all enabled Marionette.) That default is getting in the way of the
Performance Team (and others!) testing GeckoView-based products
easily.
Differential Revision: https://phabricator.services.mozilla.com/D26815
--HG--
extra : moz-landing-system : lando
The RemoteAgent.js script has (temporarily) changed name to
remote/command-line-handler.js, and the chrome component remote.jar
was not included during packaging. This patch fixes both these things.
Differential Revision: https://phabricator.services.mozilla.com/D26591
--HG--
extra : moz-landing-system : lando
Using clang-cl as a preprocessor fails with:
```
In file included from z:\build\build\src\accessible\ipc\win\handler\HandlerData.idl:8:
z:\build\build\src\accessible\ipc\win\handler/AccessibleHandler.h(27,8): error: pasting formed 'Accessible2_3.', an invalid preprocessing token [-Winvalid-token-paste]
import NEWEST_IA2_IDL;
^
z:\build\build\src\accessible\ipc\win\handler/AccessibleHandler.h(15,24): note: expanded from macro 'NEWEST_IA2_IDL'
^
z:\build\build\src\accessible\ipc\win\handler/AccessibleHandler.h(14,22): note: expanded from macro 'IDLFOR'
^
z:\build\build\src\accessible\ipc\win\handler/AccessibleHandler.h(13,36): note: expanded from macro '__GENIDL'
^
1 error generated.
midl : command line error MIDL1003 : error returned by the C preprocessor (1)
```
There's only one place using the NEWEST_IA2_IDL and accompanying
macros, we can just avoid the issue altogether by expanding it manually
(and it's not like the macro buys much, the other arm of the __midl ifdef
has a #include "Accessible2_3.h" that doesn't use the macro either,
presumably for the same reason).
Differential Revision: https://phabricator.services.mozilla.com/D24868
--HG--
extra : moz-landing-system : lando
We have a new remote protocol in Firefox that is based on the Chrome
DevTools Protocol (CDP). This is a low-level debugging interface with
which you can inspect the state and control execution of documents
running in web content, instrument Firefox in interesting ways, simulate
user interaction for automation purposes, and debug JavaScript execution.
This patch hooks the server part of this implementation, known as the
remote agent, up to the build system. The remote agent is not enabled
in the default build, so the following is needed in mozconfig to build it:
ac_add_options --enable-cdp
A subsequent change to enable the remote agent in Nightly builds only
will follow in due course. That would allow us to run TaskCluster
test jobs to verify the remote protocol's functional integrity.
Differential Revision: https://phabricator.services.mozilla.com/D22729
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
extra : intermediate-source : 276ca640adc8ff16ff3ff7252e8aa5016205b1e0
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : rebase_source : f33e1ad19c1ed06fc79e017d62765a7632578258
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
And remove the manual --enable-dmd in in-tree mozconfigs, as well as
--enable-profiling, which is implied by --enable-dmd.
This disables DMD on add-on-devel builds, which don't look like they
were actually meant to have DMD enabled in the first place (they only do
because they use the nightly mozconfig on all branches, and as a matter
of fact, the nightly mozconfig didn't enable DMD before bug 1409739)
This enables DMD on mingw builds with the same conditions applied as
other platforms, meaning that it's not enabled on opt builds on release
branches.
And this enables DMD on plain builds, which, from this perspective,
reflect local developer builds, and this is the expected effect.
Depends on D21161
Differential Revision: https://phabricator.services.mozilla.com/D21162
--HG--
extra : moz-landing-system : lando
It used to be that --enable-eme on its own had some effect, but that's
not the case anymore. The only thing it does as of bug 1300654 is to
switch the defaults in the Firefox configuration.
Reflect that in how we handle --enable-eme.
Differential Revision: https://phabricator.services.mozilla.com/D20270
Accessibility now compiles and works, so we can re-enable it!
This effectively backs out the moz.configure part of 02cd44e39566.
Differential Revision: https://phabricator.services.mozilla.com/D19650
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
AV1 is actually enabled everywhere by default (except 32-bits Windows
when building with MSVC), so let's make the option --disable-av1 rather
than --enable-av1. Also, since AV1 is backed by both libaom and
libdav1d, remove mentions to libaom.
Differential Revision: https://phabricator.services.mozilla.com/D18294
--HG--
extra : moz-landing-system : lando
AV1 is actually enabled everywhere by default (except 32-bits Windows
when building with MSVC), so let's make the option --disable-av1 rather
than --enable-av1. Also, since AV1 is backed by both libaom and
libdav1d, remove mentions to libaom.
Differential Revision: https://phabricator.services.mozilla.com/D18294
--HG--
extra : moz-landing-system : lando
We reenable the corresponding tests unconditionally because we don't run
tests on the msvc builds anyways (and they're going to be retired soon).
Differential Revision: https://phabricator.services.mozilla.com/D18028
--HG--
extra : moz-landing-system : lando
This aggregates a list of all static component manifests in the tree, and
writes them out to a `manifests-lists.json` file, which is read by the codegen
scripts in the next patch.
It slightly abuses the IDL lists machinery, given that these aren't
technically IDL files. But the semantics are similar enough that it seemed
like the best option.
Differential Revision: https://phabricator.services.mozilla.com/D15034
--HG--
extra : rebase_source : f1e1e1c9497ab8c18c25a106316a1af57237b99f
extra : source : f500020a273a27c66bf2166505a0e97bbc34a214
In some setups, MSVC is not found through vc_compiler_path, so we may
need a more complete path. `toolchain_search_path` contains
vc_compiler_path, as well as $PATH (among others), increasing our
chances.
Also, if we fail to find cl.exe that way, fail early, instead of failing
while processing config.status, failing to serialize MIDL_FLAGS because
it contains a `None`.
Depends on D17767
Differential Revision: https://phabricator.services.mozilla.com/D17768
--HG--
extra : moz-landing-system : lando
This turns out to not work at all, because this prevents MIDL itself to
pass -I to the compiler, which then proceeds to fail. We're just lucky
that our MSVC detection doesn't yield any default flags so this is
effectively dead code.
Differential Revision: https://phabricator.services.mozilla.com/D17767
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
Differential Revision: https://phabricator.services.mozilla.com/D16778
--HG--
extra : moz-landing-system : lando
This also moves the corresponding ASFLAGS from moz.build to python
configure.
Differential Revision: https://phabricator.services.mozilla.com/D16320
--HG--
extra : moz-landing-system : lando
MOZ_D3D_CPU_SUFFIX and MOZ_HAS_WINSDK_WITH_D3D are not used in the
build, and nothing includes d3d10.h except some angle code in a
preprocessed branch that is only taken for a macro we never define,
so we don't move the code corresponding to those. We also simplify the
detection code, which is convoluted now that it doesn't search for
multiple different DLLs.
Differential Revision: https://phabricator.services.mozilla.com/D16295
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
At some point we made L10NBASEDIR required. That means that
env L10NBASEDIR=... make chrome-AB_CD
takes the value set by configure. That is different than
make chrome-AB_CD L10NBASEDIR=...
which uses the value passed on the command line. Rather than making
the latter style work with `mach build`, we instead set the "correct"
value for L10NBASEDIR in automation.
We could remove the --with-l10n-base stanzas from many automation
mozconfigs, but there's some small advantage to keeping them explicit.
Perhaps eventually we will remove them -- hopefully after
standardizing l10n vs l10n-central!
Differential Revision: https://phabricator.services.mozilla.com/D15776
--HG--
extra : moz-landing-system : lando
This is a followup to bug 1515579. Interestingly, midl just tries "cl"
in the PATH, and we've been lucky that the one it finds corresponds to the
target compiler and/or that it doesn't matter what architecture the
compiler targets for idl preprocessing..
Differential Revision: https://phabricator.services.mozilla.com/D15268
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Bug 1514089 moved the check from toolchain.configure, which is only
included when a compile environment is available, to toolkit/moz.configure,
which doesn't have this limitation. As a consequence, artifact/l10n builds
ended up requiring those tools, while they didn't require them before.
Differential Revision: https://phabricator.services.mozilla.com/D14675
--HG--
extra : moz-landing-system : lando
Ideally, artifact builds would figure out the relevant buildconfig items
that are set in the artifacts they download, such as MOZ_WAYLAND,
MOZ_UPDATER, etc.
In the meanwhile, since artifacts that are being downloaded have wayland
support, we always set MOZ_WAYLAND when doing artifact builds.
Depends on D12074
Differential Revision: https://phabricator.services.mozilla.com/D12075
--HG--
extra : moz-landing-system : lando
--enable-default-toolkit=cairo-gtk3-wayland is left to _force_ wayland
support being built in, while --enable-default-toolkit=cairo-gtk3 still
allows to build against a Gtk+ version that doesn't support wayland.
Differential Revision: https://phabricator.services.mozilla.com/D11433
--HG--
extra : moz-landing-system : lando
--enable-default-toolkit=cairo-gtk3-wayland is left to _force_ wayland
support being built in, while --enable-default-toolkit=cairo-gtk3 still
allows to build against a Gtk+ version that doesn't support wayland.
Differential Revision: https://phabricator.services.mozilla.com/D11433
--HG--
extra : moz-landing-system : lando
While we do have some uses of @depends-function comparison in some
templaces, related to host/target, we ought to be using `is` comparisons
rather than `==` anyways, so we switch those, and prevent other kinds of
comparisons being used at all.
This unveils the one noted in
https://phabricator.services.mozilla.com/D7713?id=21357#inline-30414
(and surprisingly only that one), that we remove entirely since it was
doing nothing in practice. Bug 1492305 will have to add it back in a
proper form.
Differential Revision: https://phabricator.services.mozilla.com/D8501
--HG--
extra : moz-landing-system : lando
Bug 1282866 removed the only configuration where it did something.
Since then, using it only leads to a configure error.
Differential Revision: https://phabricator.services.mozilla.com/D7691
--HG--
extra : moz-landing-system : lando
This is a straightforward port of MIDL_FLAGS from old-configure to
moz.configure. The only behavioral change is that it removes support for
prepending MIDL_FLAGS from the environment in configure, but I doubt anyone
uses that.
This will be used to conditionally compile the rust code for ELF binary parsing,
which will be used by the profiler to dump symbols from system libraries on
Android.
Ideally I'd like to make this only apply to Nightly + Beta configurations, and
not to Release, but there doesn't seem to be an easy way to differentiate
between Beta and Release and doing so might be frowned upon. So now it's going
to be built on all channels on Android, even Release, even though developers
won't be profiling Release channel builds much, and the extra code size isn't
all that valuable for our users.
We definitely need this code to be included on the Beta channel, though, because
Firefox Focus Nightly uses GeckoView from the Beta channel, and we want to get
good profiling information from Focus.
Differential Revision: https://phabricator.services.mozilla.com/D7020
--HG--
extra : moz-landing-system : lando
This will be used to conditionally compile the rust code for ELF binary parsing,
which will be used by the profiler to dump symbols from system libraries on
Android.
Ideally I'd like to make this only apply to Nightly + Beta configurations, and
not to Release, but there doesn't seem to be an easy way to differentiate
between Beta and Release and doing so might be frowned upon. So now it's going
to be built on all channels on Android, even Release, even though developers
won't be profiling Release channel builds much, and the extra code size isn't
all that valuable for our users.
We definitely need this code to be included on the Beta channel, though, because
Firefox Focus Nightly uses GeckoView from the Beta channel, and we want to get
good profiling information from Focus.
Differential Revision: https://phabricator.services.mozilla.com/D7020
--HG--
extra : moz-landing-system : lando
Enable building of geckodriver by default where we have a compile
environment available. This makes --enable-geckodriver unavailable
to artifact builds.
Following this change:
* --enable-geckodriver is implied in supported build configurations,
but may be used in unsupported build configurations (Android,
cross compiled, and hazard builds) to force geckodriver to be built.
* --disable-geckodriver causes geckodriver not to be built.
* In artifact build mode, a geckodriver binary artifact will
continue to be downloaded, but it will not be possible to
specify --enable-geckodriver without a compile environment.
* --disable-tests will imply not building geckodriver, but can
be overridden using --enable-geckodriver as indicated above.
geckodriver remains disabled by default on cross compile builds
and hazard builds, pointing out Android specifically (although it
is cross compiled).
Use PrioEncoder to encode a few already-included histograms, so we can compare results on the Telemetry server side.
Differential Revision: https://phabricator.services.mozilla.com/D5088
--HG--
extra : moz-landing-system : lando
With patches from other bugs in place to use the right C compiler and cflags,
we can enable geckodriver on cross-compiles for macOS.
MozReview-Commit-ID: 5wqBiA6UCf
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
In order to start Firefox via the launcher process, we currently need to pass a
command-line flag. If we are to eventually ship the launcher by default, we want
to be able to configure the build such that the launcher process is used by
default, without any special flags.
This patch simply adds the configure option and sets the config and defines
appropriately.
--HG--
extra : rebase_source : 08847b77a8ff06314a329ae3f4ab9b7046354b30
The Rust dependency in Firefox has been limited to Firefox builds by
virtue of having the Rust check in a Firefox-specific location,
toolkit/moz.configure. For JS to start depending on Rust, we need to
move that check to a location where a standalone JS engine build will
pick up the Rust check.
Add a build option that allows to relax the requirements in
SCOPE_APPLICATION and SCOPE_SYSTEM, individually or together, in an
opt-in manner.
--HG--
extra : rebase_source : ec6b317cca17493baa9cf72675e17a1309e35a94
Summary:
AV1 is still preffed off by default and is still disabled for Android and
32 bit Windows.
Reviewers: drno
Tags: #secure-revision
Bug #: 1478005
Differential Revision: https://phabricator.services.mozilla.com/D2362
--HG--
extra : rebase_source : dc7cc50453dabb13d7abf2f1cd6eb39bb4c11f78
This implements an API in `nsIOSKeyStore.idl` and `OSKeyStore.cpp` to encrypt and decrypt bytes with a key that is stored in the OS key store.
There are two OS adapters in this patch.
Libsecret is used on Linux if available.
The NSS key store is used as fallback if no OS specific key store is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D1858
--HG--
extra : rebase_source : 99d7d646968a46a13ffa61885bb246f6d3e443e4
At some point, either bindgen will begin generating not-related-to-Stylo
things or we will start using bindgen in multiple places. Either way,
the references to Stylo should go away.
We get intermittent OOMs building aom with MSVC on win32. The PGO builds are
definitely a problem, but it may affect other builds as well. The plan for now
is to stop supporting AV1 on win32 until we switch to clang, which hopefully
is not too far away.
--HG--
extra : rebase_source : e2a754dc635d003c39cfa51b044d68a2a4a2f592
Because of bug 1423822, we can't enable elfhack and lld at the same
time. OTOH, elfhack is not really useful on local builds: it's only used
on `make package`. Since we're going to make lld the default if it's
available, let's just completely disable elfhack by default on local
builds.
While here, hide the configure flag when compile environment is
disabled.
--HG--
extra : rebase_source : 154d3059db4f0f073bd219670ef4c9bc6ebcfd26
The intent is for the build system to soon require Node.js to build
Firefox. But we aren't ready to make Node.js a build requirement
just yet.
The goal of this commit is to implement configure detection for
Node.js so that we can a) work out detection bugs b) give people a
means to validate system compatibility *before* we throw the switch to
require Node.js.
This commit introduces configure logic for finding a Node.js
executable, resolving its version, and validating its suitability.
By default, if Node.js cannot be found or there is an error resolving
its version, we print some warning messages and move on.
If --enable-nodejs is used (not the default), errors are raised
if Node.js cannot be found or its version isn't suitable.
Once we require Node.js, the added code can likely be simplified.
When writing the code, I went out of my way to make failures as
non-fatal as possible. e.g. normally we'd say that failures to run
`node --version` would be fatal. I'm purposefully trying to not have
this configure check break anyone's environment, even if failure
occurs. Again, the goal is to introduce the configure checks first
in a non-fatal way such that we can debug failures so the flag day
transition is simpler.
Differential Revision: https://phabricator.services.mozilla.com/D1818
--HG--
extra : moz-landing-system : lando
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : ee6acf7d046e8ce6e18a53988a4ea308b8d4d44f
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
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
Alex Chronopoulos
Richard Marti
Dan Minor
Myk Melez
Andreas Tolfsen
Kartikaya Gupta
Cosmin Sabou
Robert Strong
Gurzau Raul
Nick Alexander
Mike Hommey
Henri Sivonen
Adam Gashlin
Sylvestre Ledru
Ciure Andrei
Dave Townsend
Coroiu Cristina
Csoregi Natalia
Lee Salzman
Aaron Klotz
James Teh
Paul Adenot
Bogdan Tara
Kris Maglione
Andrew Osmond
Tom Ritter
Razvan Maries
Cameron McCormack
Tooru Fujisawa
Martin Stransky
Randell Jesup
Nathan Froyd
Ted Mielczarek
Markus Stange
shindli
Brindusan Cristian
Robert Helmer
Thomas Daede
Narcis Beleuzu
Franziskus Kiefer
Gregory Szorc
Chris AtLee
Dorel Luca
Takuro Ashie
Jan Beich
Emilio Cobos Álvarez
Jonathan Watt
Arthur Edelstein
Makoto Kato
Chris Manchester
Prathiksha
Ralph Giles
Noemi Erli
Sebastian Hengst
Ryan VanderMeulen
huangwenjun
qiaopengcheng
Mark Banner
Dan Glastonbury
Christian Holler
Jan Keromnes
J. Ryan Stinnett
Andrew Swan
Nicholas Hurley
Chenxia Liu
Wes Kocher