Origins will be set for any caller of CommandLineHelper.add, but will only
be propagated if args are added to extra_args. This results in an incorrect
origin recorded for mozconfig injected arguments.
MozReview-Commit-ID: 9mJCaNHyd5C
Originally, the changes to FakeCompiler allowing overlays was meant to
be used for compiler target platform, but it turns out the
simplifications this allows on the compiler definitions themselves are
nice.
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Some generated files will depend on other generated files, but still
need to be in the export tier because they are C++ headers.
MozReview-Commit-ID: AFvp92lF0xy
Mozlint provides two main benefits:
1. A common system for defining lints across multiple languages
2. A common interface and result format for running them
This commit only adds the core library, it does not add any consumers of mozlint just yet.
MozReview-Commit-ID: CSQzq5del5k
--HG--
extra : rebase_source : b520b96177281a1b1770edf53a01cbc2196f494f
- enable debug artifact from a mozconfig file based on MOZ_DEBUG environment variable
- OSX debug artifact builds have 'mac64' instead of 'mac' into their file name
(fix debug artifact build download on OSX)
MozReview-Commit-ID: 7kAvsTfwaCb
--HG--
extra : transplant_source : %E6v%25%B79M%02%7E%A9%8B%FF%24%03%D1%BDo%AB%0F%B49
Because some older python 2.7 versions throw bogus errors when using the
exec statement as a function, use the function we added in bug 1264831
everywhere we use exec in the various configure tests. It doesn't take
much to trigger them, and the following changes ends up doing exactly
that.
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime. That staticlib is then linked into libxul. For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.
For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in. The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul. Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.
This patch currently only supports Rust code in shared libraries, not in
binaries.