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
