This patch contains a number of changes to the gyp_reader code:
* Add three new flags to GYP_DIRS:
** no_chromium, to skip forcing the includes/etc needed for chromium gyp files
** no_unified, to force building all sources without unification
** action_overrides, to pass scripts used when mapping gyp actions to moz.build GENERATED_FILES
* Handle the flags mentioned above in read_from_gyp
* Handle actions in gyp targets by mapping them to GENERATED_FILES, using scripts specified in the action_overrides flag. We don't try to handle the generic action case, we require special-casing for each action.
* Handle a subset of copies in gyp targets by mapping them to EXPORTS, just enough to handle the use of them for NSS exports.
* Handle shared_library and executable gyp targets
* Handle gyp target dependencies/libraries as USE_LIBS/OS_LIBS
* Handle generated source files
* Handle .def files in sources by mapping them to SYMBOLS_FILE
* Special-case some include_dirs:
** Map `<(PRODUCT_DIR)/dist/` to $DIST/include (to handle include paths for NSS exports)
** Map include_dirs starting with topobjdir to objdir-relative paths, to handle passing the NSPR include path to NSS
* split /build/gyp.mozbuild into two parts, with gyp_base.mozbuild containing generic bits, and gyp.mozbuild containing chromium-specific bits
MozReview-Commit-ID: FbDmlqDjRp4
--HG--
extra : rebase_source : d3fb470c589f92d8c956b9ecd550fb8df79ff5bc
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
The stable cargo now has all the features we need; pulling
a separate cargo nightly package is unnecessary.
MozReview-Commit-ID: FqWvSK0swsQ
--HG--
extra : rebase_source : 3659f8fa6d4a9a70c0731650aeced899519617f9
This should have been done when autoland came into existence.
MozReview-Commit-ID: HaWNq41mDvn
--HG--
extra : rebase_source : 1f8905a45388a147970b65d6d7e226600cf8afc2
fx-team is read only. We shouldn't be performing any more builds. The
configuration can be removed.
MozReview-Commit-ID: 3cbEnnOKwaZ
--HG--
extra : rebase_source : 1e3b69721f0615327c3882767f0b90ee10bce1cf
Importing 'os' in python configure functions, on Windows, changes the
separate the various os.path functions use, and that can have
unexpected, badly handled, consequences. While on the long term, it is
desirable to make @imports('os') modify os.path to use the same base
functions as if there were no @imports, let's go with the simpler
workaround of restoring the non-{isfile,isdir,exists} os.path functions
from b6be0e9e3e1e.
--HG--
extra : rebase_source : a1857b5dce2aa818c72a77d0d9727ac6ce16cb8f
We actually target armv7, so we need this distinct triple
with the rust toolchain, while it's implicit with the
android ndk.
MozReview-Commit-ID: LUwdpOaWB6M
--HG--
extra : rebase_source : 820de90d0844e1519f9e02a583c8cc3abf1dfdc0
We want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a