Now that we have cross-compilation tooltool packages for OS X, we can
use the common mozconfig to enable Rust on all OS X builds, regardless
of host OS.
rustc, unlike our typical C++ compilers, can target multiple platforms
with ease through its use of the --target flag. To support
cross-compiling, we just need to pass the appropriate --target option.
rustc uses specific names for its accepted --target option, however, and
they are slightly different from the values we get out of autoconf. So
in addition to checking whether rustc can accept --target for our chosen
platform, we also need to munge autoconf's idea of the target into
something rustc understands.
The unix mozconfig.rust is actually completely generic now that we're
using toolchains built with --enable-rpath in tooltool.
Move the mozconfig.rust fragment up a level to reduce confusion.
When adding a backend, we currently have to add them in three different
places so that they appear in the right places.
Instead, keep the list in a single place.
The result of running this backend is a json file containing an array with 3 elements:
a map from resource:// and chrome:// url prefixes to corresponding objdir directories,
a map of overrides, and a map from objdir files to srcdir files (with a flag for whether
the file was preprocessed) for js file in FinalTargetFiles. A subsequent commit implements
the procedure to find an replace based on the url mapping, subsistute based on overrides,
and find sourcedir files based on objdir files.
The leading 'v' was intended to distinguish the detected from
the literal version string, but this is non-obvious, and could
be confused with the git tag convention.
Instead, make the strings match, but put the detected version
first since it's what configure is likely to act on.
It turns out to be much easier to hook |mach artifact install| into
config.status and |mach build| than to hook into client.mk.
The additional virtualenv package avoids an import error when running
|mach artifact install|.
Rust 1.5 features fine-grained dependency tracking that we need for
proper incremental builds. As a side effect, it also features choosing
between the builtin-to-Rust jemalloc and the system allocator, which
Gecko needs for interoperation. (Gecko needs to make Rust use the
system allocator, which then gets redirected into Gecko's copy of
jemalloc if necessary.) It's not great to require an unstable Rust
target here, but we need to upgrade at some point anyway, so we might as
well make people aware of the upgrade requirement sooner rather than
later.
Rust 1.5 features fine-grained dependency tracking that we need for
proper incremental builds. As a side effect, it also features choosing
between the builtin-to-Rust jemalloc and the system allocator, which
Gecko needs for interoperation. (Gecko needs to make Rust use the
system allocator, which then gets redirected into Gecko's copy of
jemalloc if necessary.) It's not great to require an unstable Rust
target here, but we need to upgrade at some point anyway, so we might as
well make people aware of the upgrade requirement sooner rather than
later.
This implements glandium's suggestion from
https://bugzilla.mozilla.org/show_bug.cgi?id=1227248#c5: since it's
not easy to run xpcshell tests in --disable-compile-environment builds
(and, right now, in artifact builds), let's just skip this work
entirely in those situations. This saves about 30s of build time on
my machine.
Update tooltool manifest for macosx with a custom build of rustc 1.4.0
with --enable-rpath --disable-elf-tls and MACOSX_DEPLOYMENT_TARGET=10.7
on MacOS X 10.10.5, Xcode 7.1.1 (clang-700.1.76).
Built for x86_64-apple-darwin with the rustlib from a separate
i686-apple-darwin build copied into the tree to support 32-bit cross
for universal builds.
Since we've enabled rpath, we can drop the DYLD_LIBRARY_PATH setting
from mozconfig.rust. This method seems cleaner since the add/append
decision for DYLD_LIBRARY_PATH is verbose in shell.
When I modified ehsan's patch in bug 904572 to switch to a build backend
instead of a mach command, I forgot to remove the line added to
mach_bootstrap.py to pick the mach command, which now doesn't exist.
Sccache was enabled mechanically by the switch to EC2 Windows instances, while
it is not intended to be used on PGO builds.
This happened because the fix for bug 1181040 disabled sccache for PGO builds
where MOZ_PGO is set through mozconfig (in which case MOZ_PGO_IS_SET is set)
*while* ignoring the case where MOZ_PGO is set through the environment (in
which case MOZ_PGO_IS_SET is, unconveniently, *not* set). The latter is what
Windows PGO builds do.
