clang-cl versions older than 8 are already rejected in
toolchain.configure as of bug 1550868.
Differential Revision: https://phabricator.services.mozilla.com/D64261
--HG--
extra : moz-landing-system : lando
These vary per-target, and it's nicer to define them here rather than
define them somewhere in rules.mk.
Depends on D62796
Differential Revision: https://phabricator.services.mozilla.com/D62797
--HG--
extra : moz-landing-system : lando
We're going to need this for handling Mac cross compiles correctly.
Depends on D62795
Differential Revision: https://phabricator.services.mozilla.com/D62796
--HG--
extra : moz-landing-system : lando
Legacy extensions are no longer loaded, so we can drop the build config for it. We
still need flags for handling experimental APIs since what we require differs between builds
and distributions.
Differential Revision: https://phabricator.services.mozilla.com/D57413
--HG--
extra : moz-landing-system : lando
...so that we can correctly declare that we are using sandboxed
library(ies) from our "parent" build, but not check for all the tools to
compile code.
Depends on D59554
Differential Revision: https://phabricator.services.mozilla.com/D59555
--HG--
extra : moz-landing-system : lando
This change eliminates a lot of repetition, and paves the way for the
next change.
Differential Revision: https://phabricator.services.mozilla.com/D59554
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
The remote agent used to not compile on Windows AArch64 due to iovec's
dependency on a version of winapi without support for this architecture.
Now that the remote agent has upgraded to http 0.2, which depends on
a version of the bytes crate that has moved away from iovec in favour
of std::io::IoSlice, we are able to turn on support for Windows AArch64.
This in turn will also fix bug 1606935 because the browser-chrome
test manifest for M(remote) will no longer be empty. It was a
regression caused by 1603930 where we fixed a logic error causnig
ENABLE_REMOTE_AGENT to be inappropriately set on non-trunk branches.
Differential Revision: https://phabricator.services.mozilla.com/D58767
--HG--
extra : moz-landing-system : lando
The remote agent component was meant to only be built on the
Nightly release channel, but 868b1bf043dc accidentally reversed
--enable-cdp and --reverse-cdp, not understanding that there's a
semantic difference in the build config parser for this.
This has had the undesired effect that the remote agent has been
built on all release channels since around 25th April of this year.
This in itself is not a huge concern because the feature is disabled
through the remote.enabled preference in modules/libpref/init/all.js,
except on Nightly.
This patch reverses s/disable/enable/ which causes ENABLE_REMOTE_AGENT
to be set only on the Nightly release channel, or when --enable-cdp
is explicitly used, thus achieving the original, intended effect.
We caught this when running the bc test
remote/test/browser/browser_agent.js as part of beta simulations
for Firefox 73. I wrote that test explicitly to test for this
eventuality, so I will consider it good enough for this change to
ship without additional tests.
Differential Revision: https://phabricator.services.mozilla.com/D58452
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
We often include common mozconfig fragments to turn various options on.
When doing that, environment variables are more easily turned off by
later mozconfig fragments (e.g. `build/mozconfig.no-compile` for
artifact builds) than command-line options. Therefore, include an
alternate environment variable for identifying the location of the wasi
sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D58037
--HG--
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change removes the legacy libnssdbm database that we migrated away from since Firefox 60.
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password. It otherwise removes support for libnssdbm everywhere in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
Add backend stuff to build sandboxed wasm libraries. (Don't actually update any moz.build files to consume this yet.)
Differential Revision: https://phabricator.services.mozilla.com/D54152
--HG--
extra : moz-landing-system : lando
We can't compile the remote agent startup component (written in
Rust) for Windows AArch64 due to numerous packages depending on
winapi 0.2.8 which don't support AArch64.
Differential Revision: https://phabricator.services.mozilla.com/D54116
--HG--
extra : moz-landing-system : lando
Now that rkv has a new backend, we should be able to let this ride the trains
to early beta at least.
Differential Revision: https://phabricator.services.mozilla.com/D53847
--HG--
extra : moz-landing-system : lando
Because quote([]) returns an empty byte string, configure currently
fails. While ideally, quote would return an unicode string, it is not
guaranteed that all uses of quote would actually handle this properly.
Differential Revision: https://phabricator.services.mozilla.com/D52795
--HG--
extra : moz-landing-system : lando
The MOZ_XBL define is also used in app constants and needs to be defined
for artifact builds.
Differential Revision: https://phabricator.services.mozilla.com/D48917
--HG--
extra : moz-landing-system : lando
- Update README_MOZILLA for adding mp3 support, and add some clarifying text.
- Clang-format config.h for easier reading since it is our file, not ffmpeg's.
- Use sort -d -u to produce defaults_disabled.* files so linux and macOS
produce same files.
- Change MOZ_FFVPX_FLACONLY to MOZ_FFVPX_AUDIOONLY since it indicates flac
and mp3 decoders.
- Rename config_flac.h to config_audio.h
Differential Revision: https://phabricator.services.mozilla.com/D46423
--HG--
rename : media/ffvpx/config_flac.h => media/ffvpx/config_audio.h
extra : moz-landing-system : lando
As part of compiling C/C++ to wasm, we're going to need a wasm-specific
sysroot to be provided. This option enables us to specify that sysroot
during configure.
Differential Revision: https://phabricator.services.mozilla.com/D46314
--HG--
extra : moz-landing-system : lando
This patch duplicates the configuration work done in D43710, but this
path enables better extension to other libraries and a better foundation
to build on for future build system changes.
Differential Revision: https://phabricator.services.mozilla.com/D46312
--HG--
extra : moz-landing-system : lando
This define is unused, modulo some apparently dead patches in the
gfx/skia/patches/archive/ directory.
Differential Revision: https://phabricator.services.mozilla.com/D45086
--HG--
extra : moz-landing-system : lando
Whereas previously MozDescribeCodeAddress would have handled demangling,
we need to explicitly do that from our new GetFunction method. The string we
generate is now more useful for the profiler to merge -- having dropped the
address in the previous patch, and the file & line number and library in this
patch.
While we're at it, try to demangle Rust symbols too.
Ideally we'd add Rust symbol handling to DemangleSymbol in
StackWalk.cpp, but that lives in mozglue, which currently cannot have
any Rust crate dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D43142
--HG--
extra : moz-landing-system : lando
In bug 1542830 I need to generate an import library from a .DEF file. The
`llvm-dlltool` utility is the tool to support this.
This change adds detection for the aforementioned utility and also configures
the required flags.
Differential Revision: https://phabricator.services.mozilla.com/D41817
--HG--
extra : moz-landing-system : lando
This drops the MOZ_BUILD_WEBRENDER and MOZ_ENABLE_WEBRENDER flags
which are unused after the preceding two patches.
Depends on D36820
Differential Revision: https://phabricator.services.mozilla.com/D36821
--HG--
extra : moz-landing-system : lando
There are ongoing lmdb issues we need to sort out before we can ship
cert_storage (see e.g. bug 1538541 and bug 1550174).
Differential Revision: https://phabricator.services.mozilla.com/D32885
--HG--
extra : moz-landing-system : lando
This also enables using cert_storage for OneCRL, since it and intermediate
preloading both use the same backend.
Differential Revision: https://phabricator.services.mozilla.com/D31345
--HG--
extra : moz-landing-system : lando
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