cargo 1.19, and later cargo 1.20/rustc 1.19 gained support for the make
jobserver. But that doesn't work unless make passes the jobserver file
descriptors down to subprocesses, which it only does when there is a +
prefixing commands.
--HG--
extra : rebase_source : a00ffb7edb358243ac7b9469941ec6fb5ad84885
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
All the machinery we set up for `cargo build` is equally useful for
other commands, such as `cargo check`. Let's refactor things so that
it's easy to reuse said machinery for `cargo check`.
We currently only honor LIB_IS_C_ONLY for cases where we set a
LIBRARY (and, implicitly, REAL_LIBRARY) and FORCE_SHARED_LIB. For many
libraries, such as the libraries from NSS, we never set LIBRARY, which
leads to not setting REAL_LIBRARY, which leads to not honoring
LIB_IS_C_ONLY. This practice has not been harmful thus far (except
perhaps linking in more things than necessary to our NSS shared
libraries), but on some platforms, linking with the C++ compiler will
drag in more things than we would like.
Consulting LIBRARY first should not be necessary; checking
FORCE_SHARED_LIB should be enough to tell us if we're building a shared
library for the purposes of honoring LIB_IS_C_ONLY.
We can avoid the symbol visibility problem by putting
sanitizer/asan_interface.h in the config/system-headers.
--HG--
extra : rebase_source : bc81a81ef8970c3544febf06631740208583c7fa
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)
Since we set WINVER=601 after dropping Windows XP support, it is unnecessary to define LOCALE_SNAME. So, we should remove it to remove compiler warning.
MozReview-Commit-ID: EawbHAznXNA
--HG--
extra : histedit_source : d3157300315052048756c22ac2c999523d28679d
Final target Rust programs are currently not picked up and
symlinked/copied to ${objdir}/dist/bin because the RUST_PROGRAMS output
variable is missing from the if-condition.
This change causes Rust binaries from RUST_PROGRAMS to be placed alongside
the other final target programs.
MozReview-Commit-ID: 5OIH1UMmCq2
--HG--
extra : rebase_source : cfcff21e9371b920c895ad27df344008962d7471
These paths can contain spaces, particularly if they point into
${HOME}/.mozbuild on Windows. If people are bold enough to use the
Windows packages from llvm.org, the LLVM packages are installed by
default into C:\Program Files\LLVM, so paths from there would contain
spaces as well.
Procedural macros for rust are compiled as dynamic libraries.
The compiler subsequently loads those libraries at runtime
when it compiles crates which make use of them.
We pass the generic LDFLAGS to our linker wrapper which ensures
cargo links static libraries with the correct flags. However
this also means that any final system dependency libraries
end up linked into the procedural macro dynamic libraries
whether they use them or not.
When building on macOS 10.7, this causes a SIGTRAP when dlopen
calls CFInitialize for system libraries like Cocoa off the main
thread. We believe this is a macOS bug, reported fixed in macOS 10.9.
https://openradar.appspot.com/7209349
Work around the issue by stripping those libraries and Frameworks
from the linker flags we pass to cargo. We could do a more careful
job of parsing and removing all -framework and -lfoo arguments
inside the linker script, but since this is a temporary issue
while we're using older build machines, I thought just stripping
them once in the build system was simpler.
MozReview-Commit-ID: CGXD8ARvojj
--HG--
extra : rebase_source : 33f28e8fbafb43dbdd257d9162a6e792fca79e51
We're getting an intermittent failure running `hg manifest` in CI. I
have no clue why.
What I do know is that we now have the mozversioncontrol Python package
for containing utility code for interacting with version control. It is
slightly more robust and I'm willing to support it more than I am
check_utils.py.
This commit adds a new API to our abstract repository class to obtain the
files in the working directory by querying version control.
Since I suspect cwd was coming into play in automation, I've also
added a utility function to mozversioncontrol to attempt to find
a version control checkout from the current working directory. It
simply traces ancestor paths looking for a .hg or .git directory.
Finally, I've ported all callers of the now-deleted API to the new
one. The old code had some "../.." paths in it, meaning it only
worked when cwd was just right. Since we resolve the absolute path
to the checkout and store it on the repo object, I've updated the
code so it should work no matter what cwd is as long as a repo can
be found. I'm not 100% confident I found all consumers assuming cwd.
But it's a start.
I'm not 100% confident this will fix the intermittent issues in CI. But
at least we should get a better error message and at least we'll be
running less hacky code.
MozReview-Commit-ID: AmCraHXcTEX
--HG--
extra : rebase_source : 815ae369776577ad374333920fd645d412a55148
gfx/skia/skia/src/core/SkCpu.cpp might use sys/auxv.h to detect CPU feature. So we should add it to system-headers
MozReview-Commit-ID: SijyUYvLgn
--HG--
extra : rebase_source : 0b509c2f5b4f3272578ae511e9c69cf6b0999c42
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Build system switch for optional inclusion of libaom
for support of the Alliance for Open Media AV1 video
codec.
MozReview-Commit-ID: 2C4o1ogRS9v
--HG--
extra : rebase_source : d4a68f1fc4654895f62a905666f0b75726e20e7f
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
Several years ago, joey starting writing a handful of unit tests for
primitives in our make files. IIRC a lot of the impetus behind this
work was to flush out bugs between GNU make and pymake.
AFAICT the only survivor of these tests today is check_mkdir.py. The
test is a one-off and has been a bit fragile over the years,
contributing technical debt along the way. And as part of removing the
last references to pymake in automation, it is once again showing
itself and failing in a way that has to do with the way the test
is written and not an issue with the code it is testing. Enough is
enough. This commit removes the test and eliminates the technical
debt. I don't think it will be missed.
MozReview-Commit-ID: 3OzurtFbcyD
--HG--
extra : rebase_source : 6d3cf6121c90e9c47948862b8c4117bb1d3e5afd
For linking static libraries, rustc will use whatever `cc` it finds (or
the equivalent on Windows). For our purposes, however, `cc` is not what
we use to link and we may have additional options we would like to pass
to the linker.
To do this, we need to tell Cargo about our alternate linker (currently
only used for target compilations, on the theory that the host compiler
rustc finds is probably good enough) and we also need to pass our linker
options into the process. We do this with environment variables, which
is not a great solution, but works surprisingly well.
This alternate linker is disabled for ASan builds due to peculiar
crashes when running Rust build scripts and for Windows, because we
don't do any interesting cross-compiling there.
This change paves the way for injecting target- or host-specific
environment variables for a particular `cargo build` invocation. Doing
this is not strictly necessary: all of our current `cargo build`
invocations use mostly target-specific environment
variables (e.g. PKG_CONFIG_ALLOW_CROSS). But separating things out
makes the code notationally cleaner and also avoids weirdness when
target==host.
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
By using $(REPORT_BUILD) instead of just echoing the filename, there is
no change during a regular build without REBUILD_CHECK, but specifying
REBUILD_CHECK in the environment will show which files triggered an .xpt
to rebuild. This is helpful in debugging why these files may be built
unnecessarily.
MozReview-Commit-ID: GGNaKAl02Ea
--HG--
extra : rebase_source : 098a81265deed9afc0b284d9863f18ebd74fda33
Instead of using the -i flag to clean out the entire set of environment
variables, we explicitly just clear out the variables that are affected by
32- vs 64-bit builds in vcvars.bat. This still allows cargo to use it's
internal autodetection to do host/target builds as it wants when cross-compiling,
but also allows other things that rely on include directories and so on to
work properly.
MozReview-Commit-ID: 99SECKv1zQa
--HG--
extra : rebase_source : 2c2a7d79201b66ac3262afcc5f060936ca2e8fa2
This change brings Cargo closer to what our C/C++ build already does,
and some forms of Cargo failure are only diagnosed when you pass
`--verbose`, so let's eliminate that extra step for people.
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.
This commit moves symbol dumping to the compile tier, to be run via "syms"
targets. Tracking files are used for the sake of incremental builds, because
dump_syms may genearate multiple outputs whose paths are not known ahead of
time.
Minimal changes to symbolstore.py are made here. More extensive
simplifications will be made in a future commit on the basis of symbolstore.py
handling one file at a time.
MozReview-Commit-ID: 3mOP8A6Y7iM
--HG--
extra : rebase_source : bfe97afcdfc05b9e79f01577701c83e8b00eb4e9
This creates "syms" targets that depend on the corresponding "target" for
directories containing shared libraries or programs. These targets are added
to the main compile graph in automation, and can be invoked through a special
"symbols" target. A future commit will use these targets to dump symbols for
shared libraries and programs during the compile tier.
MozReview-Commit-ID: KLuvmqsK4Zj
--HG--
extra : rebase_source : 8d76b999cb6fac8f11168ac6ebfb58774dfc2d3c
This prevents the variables set in vcvars.bat from causing build failures when
cargo tries to process build scripts in an environment where the default rust
toolchain doesn't match the MozillaBuild shell (in terms of 32-bit or 64-bit).
MozReview-Commit-ID: 5VRnQToYUYf
--HG--
extra : rebase_source : 4ac11f13e17ab04e70c7cb6f60ff46865027f506
VPATH applies to everything, but vpath applies to files matching the
pattern it's given.
--HG--
extra : rebase_source : 17339820e34f4d2f3d4ddde1a8a4325e92bfdb9e
The code doing that was already excluding OSX, so we obviously don't
need it on OSX. On FreeBSD, afaict, USDT (userspace dtrace) probes don't
require that extra ELF object. Solaris presumably does, but the 6 years
old bug 702179 says it's not been working for that long, and configure
doesn't support Solaris targets anyways.
Keeping this build system code working past the changes coming in bug
1262241 is not guaranteed and can't be tested, so I'd rather get rid of
effectively dead code rather than trying to maybe not break it while
moving it.
--HG--
extra : rebase_source : b41ab77804c17529e2580ced8e8b5fd302ff7831
This is a similar issue to bug 582910 which the stack isn't big enough
to run the tests that recurse deeply. Set it 3x larger because the
offical site states they've seen up to 3x stack memory increase for
ASan, also the number was confirmed by the measurements in bug
1259796.
MozReview-Commit-ID: FLASlkVrEUM
--HG--
extra : rebase_source : 3e82439e3df7b1e2fa1759c9693bd197431c9f71
sutagent is no longer built or used; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and test harness options like --dm_trans are eliminated.
Although bug 1322703 is backed out, we can remove -FS options to build SIMPLE_PROGRAM.
MozReview-Commit-ID: 7uO3We5hc5n
--HG--
extra : rebase_source : 6f909c4f38ba5a5bdffed7f9ca5be0030b9c681b
Depending on a library or program in misc during a pgo build causes extraneous
rebuilding due to an added FORCE dependency, so we stop adding it except during
the compile tier.
MozReview-Commit-ID: 91dZFa6IRzt
--HG--
extra : rebase_source : 9994a5c05865c81d95ea075c753e270d3c223570
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
We've been using -Z7 to make MSVC emit CodeView debug info directly in
the object files instead of in PDB files because sccache can't cache
PDB files if the same one is written to by multiple compiles, which
was previously happening in our build system, and was hard to override
in the NSS build. Now that those are fixed this should work fine.
This adds a bit to the compile rule to remove the PDB file before
compilation, since sccache won't cache a compilation if the PDB file
it is supposed to generate already exists (for the aforementioned reason).
MozReview-Commit-ID: rFlX0XfTGw
--HG--
extra : rebase_source : 8f991ce72115537466f5720c20dc53083f3b2b35
Previously, we overrode the CARGOFLAGS when we set --release
for non-debug builds. This was an oversight from bug 1310939.
MozReview-Commit-ID: LOBkCmxwDzc
--HG--
extra : rebase_source : 0325d1705cb28d6c82369abffc6fac3ca5ee6f0a
We now require cargo by version, and the minimum (0.16)
supports --frozen, so we don't need to check for this.
MozReview-Commit-ID: GPoadLkhRO5
--HG--
extra : rebase_source : e191e5dd2533e28c1bca0812f2776196cc3559cf
This makes the check_mkdir.py match the TEST-PASS output of other tests
in the suite.
MozReview-Commit-ID: FR3m09wRXg0
--HG--
extra : rebase_source : 2e59fb8bc4756a9ef9fdbcf69af80e179be80cc0
We also rename it to check_mkdir.py for consistency with other python
files.
MozReview-Commit-ID: ALuX6NUMsD2
--HG--
rename : config/tests/makefiles/autodeps/check_mkdir.tpy => config/tests/makefiles/autodeps/check_mkdir.py
extra : rebase_source : a7215c832896dd040ae2c5b3c3c2d7247c8163d8
This helps us avoid recursing over every directory when we only need to
run 'make check' in a select few.
MozReview-Commit-ID: BJ3hJBOneIz
--HG--
extra : rebase_source : 2493f924b9ccba3c779e512d7a8b7a2c26f43797
268fa5f3bc25 grafted an old patch to define --features=servo in
rules.mk. That patch was written before RUST_LIBRARY_FEATURES
existed. This commit fixes it up.
MozReview-Commit-ID: L5atm5CsP8d
--HG--
extra : amend_source : 9362db15a696ebd5871df94afb429d6f828de184
Back when the class was written, for the packaging code, it made sense
that the default was True. But now that it's used all over the place,
and that the vast majority of uses are with find_executables=False, it
makes more sense for that to be the default.
--HG--
extra : rebase_source : ff813735fc0d53093f348f20eb77ee03e9b09d4e
Make the symlinks in the dist directory relative instead of absolute.
MozReview-Commit-ID: HS7KL4JwSbV
--HG--
extra : rebase_source : 5dca673cc17423d47e6707d8800f7ee9693a9c48
moz.configure only sets the color flags value for the target compiler.
If the host compiler is a different version and doesn't support color
flags, we may pass unrecognized command line options.
Until we have better distinction between host and target compilers
throughout the build system, just disable automatic color flags for
host invocations. We don't have too many host binaries, so this should
have negligible impact.
MozReview-Commit-ID: KWTLkKvtwHs
--HG--
extra : rebase_source : 97a7240a796bae42221b2952d4dc1e66294e6219
At the same time, remove HOST_LD. It was only used for MSVC builds,
which don't support cross-compile anyways, so we can, at least for now,
use LINK for both host and target.
--HG--
extra : rebase_source : 9ee9e7e1bd3edefc043fa63d5c03f2a242f76982
The only complicating factor here is having to split out the --target
flag from cargo_build_flags, so we can pass the appropriate one
depending on our build target.
In preparation for a world where we have cargo building binaries too,
the existing rules should be renamed to reflect their library
associations. The lone Cargo invocation should be updated to explicitly
build libraries only, so libraries and binaries in the same directory
will work correctly.
Fixup a leftover comment from a previous set of changes while we're here.
iTerm2 interprets the byte sequence "ESC [ 2 i" as a request to open
a print dialog. This sequence can get emitted when printing colorized
compiler output.
Until we figure out a workaround, disable automatic coloring on iTerm2
so developers aren't annoyed.
MozReview-Commit-ID: 3Be4YgArg4k
--HG--
extra : rebase_source : e4e441a6fd97b09f55b05d53af91890649249e1c
This deprecates PYTHON_UNIT_TESTS and replaces it with PYTHON_UNITTEST_MANIFESTS.
In the build system, this means python unittests will be treated the same as all
other test suites that use manifestparser. New manifests called 'python.ini' have
been created for all test directories containing python unittests.
MozReview-Commit-ID: IBHG7Thif2D
--HG--
extra : rebase_source : 11a92a2bc544d067946bbd774975140147458caa
GCC and Clang will colorize compiler output automatically if stdout is a
TTY. Unfortunately, when the build backend is invoked via `mach`,
stdout is not a TTY.
6e9a4c0b9cd8 (bug 1315785) changed mach so it exports an environment
variable indicating whether mach's original stdout is a TTY. This was
later used to add color flags to `cargo` invocations.
Building on that work, this patch adds color flags to compiler
invocations if the compiler supports color and a mach TTY is
detected. The result is that compiler output from `mach build`
will be colorized automatically if Clang or a modern version of
GCC is used.
The only issue I see with this is that Clang doesn't "unset" its color
sequences when printing a newline. As a result, mach's time line
prefixing can sometimes inherit "bold" or other stylings. AFAICT this is
only a minor cosmetic concern. GCC does not exhibit this issue.
MozReview-Commit-ID: 5Icu6aXGZBL
--HG--
extra : rebase_source : 5b2bf5a287fdf8075b3d7dde36b91f3c65b60728
Combined with the previous patch that sets MACH_STDOUT_ISATTY, the
practical effect of this patch is that cargo is invoked with
`--color=always` when mach was attached to a TTY and colorized output
is sent to the terminal.
Note: this doesn't work with Rust/Cargo 1.10 for reasons unknown to me.
It appears there was a bug with Rust/Cargo because `--color=never` still
sent colorized output on that version! Cargo/Rust 1.12.1 works fine.
MozReview-Commit-ID: 6uXS3t3413i
--HG--
extra : rebase_source : 72df6e8248cb14c96850964f694576c7fd2f5fbb
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
--HG--
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.cpp => media/psshparser/PsshParser.cpp
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.h => media/psshparser/PsshParser.h
extra : source : 78dcbc5d3c26547c63269eb14034a67863cf28de
This patch removes the memory usage tracking in the script that wraps the
linking of the xul library. This patch also generalizes the wrapping of the
xul linking process to all platforms.
MozReview-Commit-ID: HyncF3aVwdx
--HG--
extra : rebase_source : 8fb90c896dc57793d1c9d9aa4e8492dec8697e36
Currently make check loops over all directories and runs each test file in PYTHON_UNIT_TESTS
individually. This patch instead creates a single top-level check target that runs
|mach python-tests|. This should make automation more similar to running locally, be a bit
quicker and make it easier to pull python tests out of make check completely at a future date.
MozReview-Commit-ID: 4Hg4zdFyc61
--HG--
extra : rebase_source : 31d0c38a76c11b75d3bf569f2bf22a0666161726
To support android/aarch64, I want to remove the requirement of system's libffi.
MozReview-Commit-ID: Lc3POx09Cks
--HG--
extra : rebase_source : 384852e7b9e61d0d7a950159535e3ddc8457e889
