This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
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
This reverts Bug 1355584 which made it optional for MinGW. We now use
it in MinGW so let's make it required again.
Differential Revision: https://phabricator.services.mozilla.com/D48883
--HG--
extra : moz-landing-system : lando
It is unnecessary to generate backend file for Visual Studio when building
GeckoView on Windows hsot since it has already generated Android Studio backend.
Differential Revision: https://phabricator.services.mozilla.com/D46123
--HG--
extra : moz-landing-system : lando
We only plan to run Android gtest in continuous integration on x86_64.
Given the impact on build times, I think it best to limit the gtest archive
builds to the variants where we will use it.
Differential Revision: https://phabricator.services.mozilla.com/D26936
--HG--
extra : moz-landing-system : lando
We produce two types of build symbol archives in automation:
- "crashreporter-symbols.zip" contains Breakpad-format .sym files
- "crashreporter-symbols-full.zip" contains Breakpad-format .sym files
and compressed ELF debug symbol .dbg.gz files
Right now, `--enable-artifact-build-symbols` from Bug 1305502
downloads only "crashreporter-symbols.zip".
The Android Studio version of lldb, currently 7.0.0, doesn't support
Breakpad-format .sym files. It does support (uncompressed) ELF debug
symbols. (Note that gdb isn't supported on Android and hasn't been for
some time.)
This makes ` --enable-artifact-build-symbols` download the full
symbols for Android builds that aren't in automation, to be useful for
debugging Android builds with lldb locally.
Differential Revision: https://phabricator.services.mozilla.com/D19091
--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
When doing android cross builds, the target compiler might be clang,
but it might be the one from the NDK, which doesn't come with all the
tools. So `clang --print-prog-name=llvm-objdump` might not return
anything, when the system has a suffixed llvm-objdump, e.g.
llvm-objdump-6.0.
So it's better to check with the host compiler, which is likely clang
too. We still check with the target compiler, in the odd case where the
host and target compiler would be of different kinds (Windows
cross-builds).
Differential Revision: https://phabricator.services.mozilla.com/D18142
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
Bindgen is only used when building js or toolkit, so we only need to
include the configure part in js/moz.configure, which is included in
both cases.
Depends on D16293
Differential Revision: https://phabricator.services.mozilla.com/D16294
--HG--
extra : moz-landing-system : lando
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--HG--
extra : moz-landing-system : lando
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
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
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
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.
This adds just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
Unfortunately we don't support sccache in the tup backend yet. When we
do, this check can be removed.
MozReview-Commit-ID: GonsvGv3g5k
--HG--
extra : rebase_source : 8c2edde9a6374f851b7e411b66d46bef4dc8f288
We have two checks here - first, to make sure that tup is a recent
enough version, and second to make sure that we're using the ldpreload
dependency checker. The FUSE dependency checker requires user namespaces
to track dependencies when a subprocess uses full paths, and not all
Linux distributions have user namespaces enabled by default.
Additionally, the FUSE filesystem adds significant overhead for I/O
intensive processes (such as linking libxul), which results in a bad
user experience.
MozReview-Commit-ID: H8l96dV7Qjx
--HG--
extra : rebase_source : fb6fcbc542b5757bb6c982f9e5dd51cd0f268f47
Our bundled Hunspell now significantly differs from upstream Hunspell. Most
importantly, it supports loading dictionaries from jar: URIs, which is now a
requirement for loading bundled and extension dictionaries. This means that
system Hunspell libraries are no longer compatible with our spell checker
code. We should remove the option to use them so that users don't fall into
the trap of trying to use them.
MozReview-Commit-ID: 2ihJe6YOnGf
--HG--
extra : rebase_source : ceb091b9475a2b101156405a02a60015fc36da17
This is ancient and the team that used it (gfx) is no longer using it.
MozReview-Commit-ID: HrDgmAU9QeW
--HG--
extra : rebase_source : c4a64965c4ae1a50888893e881a6e8a9688a58b6
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
Bug 1365460 introduced code paths behind MOZ_DEBUG #ifdefs, but
MOZ_DEBUG is never defined, while it is available in CONFIG in
moz.builds. This is kind of a confusing situation, but the fact that
we've been able to avoid those problems for so long would tend to
put the blame on mozjemalloc, and fixes should go there.
Except that bug 1261161 explains that the only existing alternative
(the DEBUG #define), as used in MFBT, is not working for spidermonkey,
so it actually makes sense to converge to MOZ_DEBUG rather than DEBUG.
So start defining MOZ_DEBUG globally, fixing the mozjemalloc issues of
not having the debug code enabled. Bug 1261161 can then take care of
changing the DEBUG #ifdefs.
--HG--
extra : rebase_source : 37e3d03ac8350c62c8059d4ca01d1ecfdf5f421a
When discussing bug 1395079 before it was filed, config.log didn't show
"checking watchman" while it should have. We fix this here. This also
makes it printed out in the configure output (obviously), but mach
buffers that, so when configure runs through mach, it doesn't actually
show up until the result is printed out, or, if the user interrupts
configure with CTRL+C (which is better than not showing up at all in the
latter case).
--HG--
extra : rebase_source : 11a2b5c497d7b9db3ac29cb34ff0ea2a90c179c9
See inline comment for why.
We may want a follow-up configure check for whether watchman is
usable (whether we can communicate with the daemon). This can be
deferred to another bug.
MozReview-Commit-ID: IHfyn7v7vm8
--HG--
extra : rebase_source : 90094fa60b028f06de433596f48d5a021155e2ad
Before, a non-runnable watchman would result in configure
error.
A trivial refactor to ignore `watchman version` errors would still
result in setting WATCHMAN and exposing its presence to downstream
consumers.
Since we want WATCHMAN tied to a working watchman install, we
refactor the code so that binary location and its version test
are in the same function. They are either both defined or none
of them are.
MozReview-Commit-ID: 7wvBvYuOlmJ
--HG--
extra : rebase_source : d9cc648cdb8253bf8e413ec0fa5e969aa68f75b9
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : e53928127470340275f0c0f07db72b536bba885b
extra : source : a8373914cbfd9b8595fc24f36c876cab0a26c02a
It is an optional build dependency. While we detect the version, we
don't do any minimum version checking because nothing uses it... yet.
MozReview-Commit-ID: 1tPo9AnD4fV
--HG--
extra : rebase_source : ab72057bdbcf2475902ee6b024dfa220666273f8
extra : source : 2a1b1485ffc702fb546d4c73686b5fba3e2e56dc
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : d245d316cc8a27b2827b7824204549b91465bd34
It is an optional build dependency. While we detect the version, we
don't do any minimum version checking because nothing uses it... yet.
MozReview-Commit-ID: 1tPo9AnD4fV
--HG--
extra : rebase_source : 7f547422902858671028ccd54b94dbda49b239db
Bug 1365859 introduced a dependency on the Visual Studio binary 'fxc'
to generate Shader bytecode. This was unavailable when compiling for
Windows on Linux as part of a MinGW build.
This commit adds a configure check for fxc, and also searches for
fxc2, which was written (https://github.com/tomrittervg/fxc2) to be
a tiny application that wraps D3DCompileFromFile and can produce
similar (but not exactly the same) output as fxc.
fxc2 is compiled using MinGW for Windows, and runs under wine, so
we need to check for wine also.
Finally, fxc outputs some include information fxc2 doesn't, so
we will just change that assert to not take effect.
MozReview-Commit-ID: 8LVxuODi6cV
--HG--
extra : rebase_source : 39acca112f4cd9e6c39f7e47e7c55b13e7606824
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
We eventually want to templatize the library_name_info function, in
order to have one for host and one for target. So we don't want 3
different dependencies for the target.
--HG--
extra : rebase_source : cc980a5da9a35e71856ef970a58b2edcd05615c6
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
SO_VERSION has only an impact on those builds. Also set the default at
the option level, instead of doing that in the library_name_info
function.
--HG--
extra : rebase_source : 29aa61beeaede7d43daec599866094b91f2e7a82
This happen to uncover the fact that mingw clang was not handled
properly after bug 1372987. This will allow us to substantially modify
the function that handles them and avoid regressions.
--HG--
extra : rebase_source : 007257caecf7917480ef6b0a834c304768f77591
For parts of configuring Stylo, we need information about the library
extensions on all of our platforms, and this change is a reasonable way
to get at that information without duplicating it in two places. Plus
moving more things to moz.configure is more better.
This involves a few changes:
- Remove the .exe from the makensis binaries. which.which will
auto-add it so Windows will keep working - and with it
present we were finding makensis.exe on Linux and trying to
run it, which isn't going to work
- Doesn't bother checking if nsis is 32bit if we're running on
Linux
- Add the -nocd option to nsis (on Linux) because it takes the
current working directory from the target of a symlink rather
than the symlink itself. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704828
MozReview-Commit-ID: CVT8LwS1t8w
--HG--
extra : rebase_source : 2a62327326ba80dfd728048d19f0ff1c90100838
For people working on Rust code, compiling in debug mode (Cargo's "dev"
profile) is convenient: debug assertions are turned on, optimization is
turned off, and parallel compilation inside of rustc itself can be
used. These things make the build faster and the debugging experience
more pleasant.
To obtain that currently, one needs to --enable-debug at the Gecko
toplevel, which turns on debug assertions for the entire browser, which
makes things run unreasonably slowly. So it would be desirable to be
able to turn *off* debug mode for the entirety of the browser, but turn
on debug mode for the Rust code only.
Hence this added switch, --enable-rust-debug, which does what it
suggests and defaults to the value of --enable-debug. For our own
sanity and because we judge it a non-existent use case, we do not
support --enable-debug --disable-rust-debug.
Andreea Pavel
Thinker Li
Greg V
Bogdan Tara
Ricky Stewart
Narcis Beleuzu
Tom Ritter
Makoto Kato
Rob Lemley
Mike Hommey
Geoff Brown
Ciure Andrei
Nick Alexander
Rob Wu
Razvan Maries
Nathan Froyd
Cosmin Sabou
Dorel Luca
Chris Manchester
shindli
Tooru Fujisawa
Robert Bartlensky
Csoregi Natalia
Ted Mielczarek
Sofia Carillo
Mike Shal
Kris Maglione
Nathan Froyd
Felipe Gomes
Ryan VanderMeulen
Gregory Szorc
Sebastian Hengst
Andrew Osmond
Carsten "Tomcat" Book