- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--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
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