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.
This makes it clearer that really it's the same thing as FINAL_TARGET,
with preprocessing.
We still keep DIST_FILES in backend.mk because it's shorter and doesn't
really matter.
Write a mozconfig.rust fragment which makes the rust toolchain
provided by tooltool available for linux builds, similar to
what we do for MacOS X.
Include this in linux64 mozconfigs to enable rust for official
nightly builds of that target. These aren't used outside of automation
builds, so including rust there will verify code on check-in
without requiring developers to install rust.
We must whitelist the mozconfig fragment to pass the consistency
check since we're not ready to let this feature ride the trains
to beta and release.
The tooltool reference is to a custom build of rustc 1.4
with --enable-rpath to avoid having to add the rustc lib
directory to LD_LIBRARY_PATH which somehow conflicts with
the gtk3 build we also install through tooltool.
It is also built with --enable-llvm-static-stdcpp on a
rust-buildbot dist docker image (centos:5 + script updates)
to avoid issues with GLIBCXX and GLIBC symbol versions.
Pymake's clinetoargv is very specific to pymake's use case, yet has been abused
as a replacement for shlex because shlex doesn't handle things properly for our
use cases.
Using pymake's clinetoargv, however, has shortcomings, and we're better off
importing its code in mozbuild, simplifying it a little, and using that
instead.
Plus, less dependencies on pymake will help kill it for good some day.
XPCOM binary components imply dependent linkage, don't work with msvcrt
static linkage and have to be built against mozglue, so let's remove all
the footguns changing those add.
Landing as one rolled-up patch to avoid breaking regression tests, and in
keeping with previous WebRTC imports. Broken out parts that needed review
are on the bug.
In order to meet the addon signing requirement for tests, specialpowers
needs to be installed at gecko runtime. This means it must be restartless.
This patch packages specialpowers as a restartless addon, but it does not
yet install it at runtime.
Pretty straight-forward. The win here is that the directory is now
sensible, so we don't need the robocop_harness symlink for the Gradle
build configuration.
Pretty straight-forward. The win here is that the directory is now
sensible, so we don't need the robocop_harness symlink for the Gradle
build configuration.
This moves the Robocop test code into
src/androidTest/java/org/mozilla/gecko/tests. The
src/androidTest/java is Gradle standard; the org/mozilla/gecko/tests
matches the package name we have now.
