It's already included by the nightly and debug mozconfigs which end up including
cross-mozconfig.common, including it again appears ineffectual and causes
failures in artifact builds.
MozReview-Commit-ID: 1DH4r8mgNXe
--HG--
extra : rebase_source : d01254a2140ad6fc90321c8a5d1f4c439e93f7b1
The `cd $PATH && pwd` pattern doesn't work when $PATH doesn't exist, so
move them in a block only executed when the directory exists.
--HG--
extra : rebase_source : 53bd2959dbd9825526a386b6ab5b40a7f67a5d20
The build will fail during configure anyways in that case, not silently
fallback to compiling without it.
--HG--
extra : rebase_source : 8f12f64da6a635e63339a988f27ada893f567712
This imports two modules from mozregression in the tree to do so. They
are imported from current trunk on github, rather than the version we
were getting from pypi.
Note we take six from testing/web-platform/tests/tools/six) instead of
moving it to python/six because it's there by coming from a copy of
https://github.com/w3c/wpt-tools, which contains it as a submodule, and
moving it would make updates there harder.
--HG--
extra : rebase_source : 16619d1c3f38f6493fb490a64361b3f4e8fecc1f
Rust libraries can set RUST_LIBRARY_TARGET_DIR so that they can share
compilation artifacts with other libraries. This setting needs to be
propagated to the backend so it can be communicated to Cargo.
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
We've been using -Z7 to make MSVC emit CodeView debug info directly in
the object files instead of in PDB files because sccache can't cache
PDB files if the same one is written to by multiple compiles, which
was previously happening in our build system, and was hard to override
in the NSS build. Now that those are fixed this should work fine.
This adds a bit to the compile rule to remove the PDB file before
compilation, since sccache won't cache a compilation if the PDB file
it is supposed to generate already exists (for the aforementioned reason).
MozReview-Commit-ID: rFlX0XfTGw
--HG--
extra : rebase_source : 8f991ce72115537466f5720c20dc53083f3b2b35
We now require cargo by version, and the minimum (0.16)
supports --frozen, so we don't need to check for this.
MozReview-Commit-ID: GPoadLkhRO5
--HG--
extra : rebase_source : e191e5dd2533e28c1bca0812f2776196cc3559cf
This removes the UNIFY_DIST and UNIFIED_BUILD variables, as well as the
--unify flag from the packager and UnifiedBuildFinder from mozpack. As a
result the STAGEPATH variable is never defined anymore, so its uses can
be removed as well.
test_unify.py is currently the only mozbuild/mozpack test that fails
without running configure first, and there isn't much point in fixing
tests for things that we don't actually use anymore.
MozReview-Commit-ID: F5q1FPW3Did
--HG--
extra : rebase_source : cadbd237f51c23ea1983135294521d628d16f0df
This replaces the 'run-tests-deps' make target with a python function that will directly
read moz.build files, emit them with TestManifestEmitter, then consume them with
TestManifestBackend. Because the TestResolver is the only place that actually reads the
test metadata files, we can remove this logic from the CommonBackend as well.
MozReview-Commit-ID: DXgMoeH5dKf
MozReview-Commit-ID: HstZ57qkqf2
--HG--
extra : rebase_source : f377fa6863ef66d3adb86ed64f844e346686862f
Looking into the config.status path some more, the reason we always rebuild when it is not present is because of the way I implemented missing files in bug 1242663. However, I think an alternate solution there would be to use $(wildcard) instead of creating dummy rules on every file. so if our dependency file contains:
config.status
foo
bar
The current rules do:
backend.TestManifestBackend: config.status foo bar
re-create backend
config.status foo bar:
Since config.status is missing, make runs the empty rule to try to create it (which does nothing), but that triggers the backend.TestManifestBackend rule. With wildcard this would look like:
backend.TestManifestBackend: $(wildcard config.status foo bar)
re-create backend
Which means make only checks dependencies on the files that actually exist (presumably foo and bar in this case, but not config.status). But when config.status is later created, we'll know to recreate the TestManifestBackend then.
MozReview-Commit-ID: 6NTTmsnxTeT
--HG--
extra : rebase_source : 737c3021cbc26074ec54eafeca203ae95c37d8b8
These automation steps are no longer relevant, since the last use of
MOZ_AUTOMATION_PRETTY was removed along with non-unified builds in bug
1121000.
MozReview-Commit-ID: 11VDu8pIs1p
--HG--
extra : rebase_source : a82b52400b73224e06e124dd10d6646d4b21a7fc
Bump the minimum version of the rust toolchain we require to
build. The 1.15 release includes support for custom #[derive]
directives, letting us use the serde serialization crate without
checking in a lot of generated code.
This is primarily motivated by webrender and the audio remoting
work, and lets us drop the heavy syntex dependency.
MozReview-Commit-ID: 6IObHhouPAn
--HG--
extra : rebase_source : 4be8b148fb653a48f6df4309811ab1d8755f7edf
We can just check the GPG signature for the upstream tarballs that are
GPG signed. We keep a copy of the relevant GPG keys in tree so that
we only use a controlled set of keys.
I validated the GPG keys by:
- Creating a fresh keyring.
- Importing the keys with gpg --receive-key.
- Importing my own GPG public key in that keyring.
- Importing the gpg keys that the PGP pathfinder told me were on the path
to those keys (which weren't directly in their keyring, so I had to
manually find some steps first).
- Using `gpg --check-sigs` to validate that the all those keys I got are
the right ones.
Then the relevant GPG keys were exported with `gpg --export --armor` and
stripped with https://github.com/glandium/pgpstrip/.
For MPC, the first GPG-signed version upstream was 0.8.2, while the GCC
script to download prerequisites downloads 0.8.1. So instead of using
0.8.1, we use 0.8.2, which we can verify.
For GMP, the GCC script downloads 4.3.2. The only web-of-trust path is
through a revoked key, which signs a revoked uid of the GMP key.
Releases newer than 5.1.0 are signed with a new key that can be
validated with the steps above. So instead of using 4.3.2, we use 5.1.3
(last of the 5.1.x line).
But MPFR 2.4.2, which the GCC script downloads, doesn't build against
GMP 5.1.3, so instead of that, we use MPFR 3.1.5.
Sadly, the remaining GCC prerequisites are not signed, so I had to:
- Download the files from ftp.gnu.org.
- Download the corresponding files from snapshot.debian.org.
- Compare the raw files when possible, or the uncompressed (not extracted)
files (when, thankfully, they matched).
- Validate those snapshot.debian.org files checksums against the
checksums in the corresponding Sources.bz2/xz files.
- Validate the Sources.bz2/xz checksums against the corresponding InRelease
files.
- Validate the InRelease files GPG signatures against the Debian
archives keyring.
With all those things we actually don't get through the GCC script, we
also change how we get those prerequisites, by diverting the commands
the script runs and making it output the urls instead of downloading and
extracting the files.
All downloaded files, GPG-validated or otherwise, have their SHA-256
digest checked against a list in build/unix/build-gcc/checksums.
--HG--
extra : rebase_source : e6809a6ac392e6c5f99801826e1d30bdeee7ddf5
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
This ensures that we correctly link against /usr/lib/libc++.1.dylib.
With this flag left in LDFLAGS, the linker would find libc++.1.dylib in
clang/lib, which would cause us to link against @rpath/libc++.1.dylib.
In bug 1296530, we made @depends take a when argument, it can now replace
all uses of @depends_when.
--HG--
extra : rebase_source : d090723fcbf3a56e06bd9c2defc3301cac04d8b0
Remove the option to build without rust code. We are not testing
this configuration and expect to land non-optional rust code in
the near future, so it doesn't make sense to maintain this option.
MozReview-Commit-ID: CwTlMXGvr5n
--HG--
extra : rebase_source : 080a9df5b4828c66aa2452ad1c16a503bcd5e689
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
In bug 1320194 we want to generate a TestManifest backend without first
invoking configure. However, we still need a way to update the backend,
which is normally handled by the top-level Makefile. We can split this
logic out into a separate file, rebuild-backend.mk, which can be invoked
directly as long as the appropriate environment variables are set
(BUILD_BACKEND_FILES, BACKEND_GENERATION_SCRIPT, and PYTHON).
--HG--
extra : rebase_source : b6a486db3e3c97b406b11074fda052bd63fe1b8f
We want to avoid giving --help dependencies to host and target, so that
they we don't spawn config.guess and config.sub when running configure
--help, and don't need to reach out to the which module to find a
suitable shell to execute them.
So, when --help is given, we return a fake host/target namespace, and
avoid the config.guess/config.sub-invoking code being executed.
Then, by giving the --help option to the linter, it can properly find
that the config.guess/config.sub-invoking code doesn't need the
dependency on --help.
This effectively unbreaks configure --help after bug 1313306.
--HG--
extra : rebase_source : 9ed4cbe5a81121b139d0d86aff6af542c2dff53b
The return-empty-string-non-mangled.patch apparently landed in r249437
upstream, so we don't need to carry around our own version. The patch
is still nominally used for building clang on Mac, so I have not removed
it from version control.
