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