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
from https://github.com/parkouss/dlmanager
Note this technically should come before the first patch, but mozreview
won't show useful interdiffs if I do that, so I'll reorder the patches
before landing.
--HG--
extra : rebase_source : dedca9393783623461509c7c85e35302f4b08a2a
Cargo hashes various compilation settings into the dependency graph for
dependent libraries. So if the compilation settings for gkrust and
gkrust-gtest are different, their dependencies will likewise be
different. The setup we've created in the previous patches depends on
the compilation settings being identical, so we should enforce that at
the moz.build level.
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.
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 helps us avoid recursing over every directory when we only need to
run 'make check' in a select few.
MozReview-Commit-ID: BJ3hJBOneIz
--HG--
extra : rebase_source : 2493f924b9ccba3c779e512d7a8b7a2c26f43797
This adds the ability to use manifestparser subsuites to |mach python-test|.
Subsuites are based on the premise of a "default" set that gets run when no
subsuites are explicitly specified. When a test is labelled with a subsuite,
that test is removed from the default set and will only run if that subsuite
is explicitly specified. This will allow us to chunk python unittests out of
'make check' piecemeal. The default set will run in 'make check', and
individual tasks (e.g mozbase), will specify a subsuite explicitly.
The |mach python-test| implementation is slightly different. By default,
subsuites are not considered if developers do not pass in --subsuite. This
means running |mach python-test| without arguments will still run the full set
of tests, and similarly, passing in test paths will *just work*.
If for some reason a developer needs to actually run the default set, a special
"default" subsuite has been create, so they can use
|mach python-test --subsuite default|. This default subsuite is also what 'make
check' will explicitly invoke.
MozReview-Commit-ID: FaHb4nvuoK9
--HG--
extra : rebase_source : 2ecbc902bb6bafa7cd78ac0e380a10bad7c14351
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
Currently, the only way to emit objects after reading moz.build, is to emit everything. Though, sometimes
it may be desirable to only emit certain types of objects. This adds a new argument that allows consumers
to specify a custom emitter function. This gives them the flexibility to do whatever they want.
This will be used when resolving tests, so only TestManifest objects are emitted.
MozReview-Commit-ID: DPGgNmn2JvE
--HG--
extra : rebase_source : 044f8c8cad1bf7fd1dfbed05c89fbd114508182a
This is a drive by fix that is not relevant to the rest of the commit series.
MozReview-Commit-ID: Bwrb74o3Qh8
--HG--
extra : rebase_source : 34706a6640a6c704f9c03f24aede71e4c1c5ac1c
Currently the CommonBackend is responsible for processing TestManifest objects and using them to generate
the test metadata files (e.g all-tests.pkl et al). This patch pulls that logic out into a partial backend
specifically for test manifests.
This patch is solely a refactoring and shouldn't change any build behaviour. CommonBackend has a
TestManifestBackend instance and calls consume_object directly on it. However, this is just a temporary
measure to avoid checking in a broken commit.
This commit also adds a test for the 'test-defaults.pkl' file which was previously missing.
MozReview-Commit-ID: HOr2QVT8CJ1
--HG--
extra : rebase_source : e4b9cb982937381346c0821971191277173b165b
When vendoring third-party files, we'd like an explicit notice/review
when said files contain a "large file". This commit adds such checks
for files vendored via `mach vendor rust`.
As we don't yet have a server-side hook in place to prevent large files
from being added, we just have a command-line flag that people are
expected to use, on the honor system, to permit large files to be added
when vendoring.
This command is useful for users who wish to perform something like the
following:
1. Add/remove a bunch of files;
2. Examine the additions/removals/modifications for interesting changes;
3. Reject the add/remove if it doesn't meet some set of conditions.
The FileNotFoundError built-in exception is only present in
python 3. Emulate its behaviour in python 2 with a conditional
OSError.
MozReview-Commit-ID: 4b8THPG7jph
--HG--
extra : rebase_source : 718bf3659f14bd349d052d43bf3197dfbb4a016f
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
Without this, clang-tidy cannot check any diffs including such files.
In the future, when checking the entire tree using clang-tidy, we will
ignore these entries in the compilation database.
The way directory traversal is computed relies on the
RecursiveMakeTraversal class, which is used to reproduce the old
traversal order from the old entirely-in-make traversal with DIRS,
PARALLEL_DIRS, etc. because of the undeclared intra-directory
dependencies that are looming here and there.
It's fed through DirectoryTraversal objects emitted by the frontend.
Normally, DirectoryTraversal objects are emitted for a directory,
possibly giving the subdirectories defined in DIRS/TEST_DIRS its
moz.build. But in the case of gyp processing, nothing places the gyp
objdirs in some virtual DIRS of some parent moz.build since bug 1308982.
As a consequence, the corresponding entries in the
RecursiveMakeTraversal instance attached to the backend are not attached
to any parent directory. When subsequently traversing the tree from the
root, they are never found, and end up being skipped, irregarding of
their actual _no_skip status.
It would probably be possible to revert the changes from bug 1308992,
but we might as well not rely on remains from the old ways. So instead,
we make the RecursiveMakeTraversal consider directories without a
declared parent attached directly to the root directory. They don't need
to depend on any other directory anyways.
--HG--
extra : rebase_source : 17403922322a71d490fdea8db0ff16b04983ed7a
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
We had been installing them to dist/plugins with the rest of the test plugins,
but tests are actually expecting them to be in dist/bin.
MozReview-Commit-ID: 9qYFgZA4Fni
--HG--
extra : rebase_source : 52a4cbf70ffe7998cfe81ab5e508b9f802dd3a35
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
This updates the client artifact code to locate test support files in the
common test archive and populate the objdir with these files appropriately.
MozReview-Commit-ID: GuXjwUtsl
--HG--
extra : rebase_source : 3560efee22533f60be1e7394fa0841005991cca6
Generated support files for specific tests generally end up in a harness specific
test archive, but artifact builds, which might not want to generate these files
themselves, get all of their test related files from the common.tests.zip. This
effectively moves a small number of these support files from harness specific
archives to the common test archive, making it possible to run tests that
depend on these files against artifact builds.
MozReview-Commit-ID: BvEj1ot1OTw
--HG--
extra : rebase_source : 06e958adc7b5667c50ca5ddbf06c1bf878d75737
Install manifests influence test packaging, allowing artifact builds to consume
generated test support files and run tests that depend on them. This commit
tracks binaries with an install target under "_tests" so they will be correctly
installed in artifact builds.
This could similarly be achieved by installing the binaries via TEST_HARNESS_FILES
rather than setting FINAL_TARGET, however, PGO builds will fail attempting to install
the files during the profile generation step, because SIMPLE_PROGRAMS are not built
for this step.
MozReview-Commit-ID: ES4bTxOoqMN
--HG--
extra : rebase_source : f41d8c47711fc15247fa336e2e9cbdedf57c2daf
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
And make it an error not to give it. While the default is True, we do
pass a value of False wherever it makes sense, which happens to be, in
most places.
This is an intermediate step to flip the default from True to False,
ensuring that we don't unwantedly switch some calls to False.
--HG--
extra : rebase_source : 432e03f032fef378af482581685583262e5d2661
