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
