Because we're going to change how cargo recipes are called to export
environment variables rather than by wrapping the call with `env`, to
avoid msys roundtrips, it's better to avoid the complexity when not
building rust, and including a separate file only when required helps
with that. It is also possible to wrap the entire rust section of
rules.mk in the same condition we use for the include, but using a
separate file also makes things clearer.
Differential Revision: https://phabricator.services.mozilla.com/D18180
--HG--
rename : config/rules.mk => config/makefiles/rust.mk
extra : moz-landing-system : lando
We default to -Zi for Windows debug flags, which is for generating debug info
into a PDB file, but clang-cl doesn't actually implement that so -Zi is
an alias for -Z7 in clang-cl:
http://clang.llvm.org/docs/UsersManual.html#id9
sccache has special handling for -Zi because multiple compiles writing
to the same PDB file is not cacheable, so we've always overridden -Zi with -Z7
in CI when using sccache.
Given that everyone should be using clang-cl nowadays and MSVC will no longer
be supported soon, this patch changes the default and removes some PDB
file name flag setting from rules.mk, as well as the no-longer-necessary
overrides from mozconfig.cache.
Differential Revision: https://phabricator.services.mozilla.com/D18264
--HG--
extra : moz-landing-system : lando
Now that everything is lined up nicely, we don't need those anymore.
We can fill cargo-linker.bat with HOST_LINKER and HOST_LINKER_LIBPATHS,
which, unfortunately, can't be used as is, so we add a variant for
substitution in .bat files.
Differential Revision: https://phabricator.services.mozilla.com/D18034
--HG--
extra : moz-landing-system : lando
The only use in configure itself is for a MSVC version check that is now
always true (we don't accept versions < 19.15 anymore).
The only uses in the build system are in code that could just use
CC_TYPE instead.
Differential Revision: https://phabricator.services.mozilla.com/D17207
--HG--
extra : moz-landing-system : lando
Because MSVC compilers only support one architecture, we need to search
"cl" in different toolchain search paths for each of the host and
target, especially when they are different.
Likewise for the library paths for the linker. Ideally we'd pass
-LIBPATH both for host and target, but that has implications for rust
that I don't want to have to figure just now.
Depends on D15263
Differential Revision: https://phabricator.services.mozilla.com/D15264
--HG--
extra : moz-landing-system : lando
None of the values tested against OS_TEST are actually possible per
split_triplet in build/moz.configure/init.configure, so the code is
dead in practice.
Differential Revision: https://phabricator.services.mozilla.com/D16161
--HG--
extra : moz-landing-system : lando
The build system has skipped creating target static libraries for very
long, except in very specific cases.
We can actually do the same for host static libraries, for which we
don't even need the escape hatch to still allow to create static
libraries.
Depends on D15171
Differential Revision: https://phabricator.services.mozilla.com/D15172
--HG--
extra : moz-landing-system : lando
OBJ_SUFFIX is modified during the profile-generation phase to be i_o
instead of o/obj. _OBJ_SUFFIX is the unmodified value.
We don't actually do PGO for host objects, so we don't need to build the
objects with a different suffix.
Differential Revision: https://phabricator.services.mozilla.com/D15171
--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.
- Embed vendored Rust dependencies into the source package.
- Don't use --freeze with Cargo in JS standalone builds: since all the Rust
dependencies are vendored in, it won't trigger an update of the toplevel
Cargo.lock file for a standalone build in the non-package build case.
--HG--
extra : rebase_source : 06704eb326aad36a870586694a99964ad7a4dbfa
extra : histedit_source : 1502d976bc12a3eed17efaaf5dd2d4f46d0b00d5
This makes it more apparent which directory is responsible for creating
a particular generated file, program, library, etc. It is particularly
helpful in bug 1485081 since all node.py invocations will have similarly
named make targets, but run in different directories.
MozReview-Commit-ID: HlSOiL34i3M
Differential Revision: https://phabricator.services.mozilla.com/D6822
--HG--
extra : moz-landing-system : lando
BUILD_TOOLS was only ever used for things that another variable provides
equally well. Removing BUILD_TOOLS means that we can remove win_srcdir
and WIN_TOP_SRC as well.
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
MSVC 15.8 linker dislikes forward slashes in the /OUT: parameter when it is generating a profile
--HG--
extra : rebase_source : 6980e212ea5a7ae21513805c22ec0e8ddeaa5dc1
MSVC 15.8 linker dislikes forward slashes in the /OUT: parameter when it is generating a profile
--HG--
extra : source : d0098304d5b1a35446781d60a9050d310b45f5bd
Previously we weren't passing the variables if we were compiling for Windows
when really we only want to do it if we're compiling with MSVC/clang-cl.
The MinGW-Clang build needs this.
Differential Revision: https://phabricator.services.mozilla.com/D3470
--HG--
extra : moz-landing-system : lando
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
For "real" Windows-to-Windows cross compiles, the setting of
HOST_OUTOPTION is incorrect: it assumes that if we are cross-compiling,
we'll be using `-o ` (GNU-style) rather than `-Fo` (MSVC-style). Our
normal x86 Windows automation builds are technically not
cross-compiles (host and target are both x86 Windows), so this case has
never bothered us before. But when compiling for AArch64 Windows, we
are really doing a cross-compile, and so we need to be more careful
about how we set this option; otherwise, host compilations will
mysteriously fail because they won't produce any output.
For clang-cl, we want to add code to libxul that only exists during the
PGO generation phase, so we can collect data. The most expedient way to
do that is to enable certain files in SOURCES to be marked as to only be
compiled during the PGO generation step.
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
Mike Hommey
Ted Mielczarek
Tom Ritter
Chris Manchester
Marco Castelluccio
Nathan Froyd
Benjamin Bouvier
Mike Shal
Thomas P.
Andreea Pavel
arthur.iakab
Adam Gashlin
Masatoshi Kimura
Margareta Eliza Balazs
Gurzau Raul
Myk Melez
Narcis Beleuzu
Aaron Klotz
Nathan Froyd
David Major