Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
There can be cases where there is simply nothing to download, especially
with the --for-job argument. So we just stop erroring out when nothing
was downloaded.
However, if the user explicitly requested a particular file(s) via the
command line and there is nothing to download, we still emit an error
code.
--HG--
extra : rebase_source : 143c15c9711bbfbbfdc110da14f3738132d53ed4
This patch does a few things:
a) Adds the resources location from the .app directory to the read whitelist
b) When it's a non-packaged build, mach run (and various mach tests) set an environment variable for the repo location which we allow reads from.
r=haik,froydnj
MozReview-Commit-ID: KNvAoUs5Ati
--HG--
extra : rebase_source : 81ba8bfee0ca96979cf8e30d75cdd47f06bc10ea
This patch does a few things:
a) Adds the resources location from the .app directory to the read whitelist
b) When it's a non-packaged build, mach run (and various mach tests) set an environment variable for the repo location which we allow reads from.
r=haik,froydnj
MozReview-Commit-ID: KNvAoUs5Ati
--HG--
extra : rebase_source : f637acff32fc8582732de932503dd696abc57877
Now that we have automated build jobs that produce toolchains, we want
to avoid the burden of uploading them to tooltool and then update the
tooltool manifests. But we don't have build jobs for all the possible
toolchains, so we allow `mach artifact toolchain` to get a mix of
tooltool and taskcluster artifacts.
For taskcluster artifacts, we can give a list of job names (conveniently
automatically normalized to begin with 'toolchain-' and end with '/opt')
for which the artifacts will be downloaded, in place of any tooltool
package with the same name (if a tooltool manifest is given).
The taskcluster artifacts that we download are the ones matching the
contents of the tree the command is run with, per the resources declared
for the corresponding toolchain build job (in
taskcluster/ci/toolchain*.yml)
So for example, a linux64 build could call the following command:
mach artifact toolchain --tooltool-manifest \
browser/config/tooltool-manifests/linux64/releng.manifest \
--from-build linux64-gcc
and get the right gcc corresponding to the build-gcc script in tree,
along with the other non-gcc files from the tooltool manifest.
Things are however planned to be even more convenient, but some commands
can already benefit from this form (even without a tooltool manifest).
See e.g. bug 1328454.
--HG--
extra : rebase_source : b12ed77bef529eb8d67476aceac0166bdfe2eeed
We're going to potentially use the same download manager for tooltool
and taskcluster artifacts, and we don't want to send the tooltool
authentication header to the taskcluster requests.
--HG--
extra : rebase_source : 79a0afdbf06cb05d7792f413ab1f6715b2a9fe2e
beb43155b7a6 changed WPT items to be 3-tuples instead of 2-tuples.
This broke test_defaults_for_path().
MozReview-Commit-ID: 7M0RcQ7bOIU
--HG--
extra : rebase_source : 28e44e5206abb7939d540ba809ec71325ead341c
At the same time, make the artifact cache directory not indexed, and
move the directory creation to the base classes that actually use it.
--HG--
extra : rebase_source : 62994499afceb5166c0041148dcc702f87166fdc
The ultimate goal is to have a generic command that pulls relevant
toolchains from either tooltool or taskcluster artifacts.
This introduces the command and makes it work to allow to wrap tooltool
in most places where it's used currently, with the ability to replace
tooltool_wrapper.sh as well.
--HG--
extra : rebase_source : f63178282f00f8698a148db484f0276c99d61f7b
Profiling revealed that mozpath.relpath() accounted for a lot of CPU
time when operating on an input of ~42,000 paths.
Due to the nature of the paths we're operating on, we don't need the
full power of mozpath.relpath() here. Instead, we can implement a
specialized version that works given already normalized paths and the
knowledge that context paths must be ancestors of the current path
being examined.
This change drops execution time of a mach command feeding ~42,000
paths to this function from ~90s to ~24s. On an input with 9131 paths,
execution time dropped from ~8.8s to ~3.7s.
MozReview-Commit-ID: EGLiJa10Zj2
--HG--
extra : rebase_source : 8e9d7a957ea3d865a6f18a3b99cca2b22f7a0385
Calling self.test_defaults_for_path() from files_info() with tens
of thousands of paths resulted in a CPU explosion in various path
normalization functions. I don't think it was so much the complexity
of the operations as much as the volume.
For an input with 9131 elements, this reduces execution time of a
mach command from ~25.7s to ~8.8s. With ~42,000 inputs, execution time
drops from <it took too long and I gave up> to ~90s.
MozReview-Commit-ID: pjQQByi2Bc
--HG--
extra : rebase_source : b8307a92e494f128ba3cf29348bc7996cfea4221
With ~42,000 entries in relpaths, this change drops execution time
of this loop from ~23s to ~0.01s.
MozReview-Commit-ID: Afm245tjWUQ
--HG--
extra : rebase_source : 86ee525b0539c80e47e4326a3f111a3fc84d0a6e
For people working on Rust code, compiling in debug mode (Cargo's "dev"
profile) is convenient: debug assertions are turned on, optimization is
turned off, and parallel compilation inside of rustc itself can be
used. These things make the build faster and the debugging experience
more pleasant.
To obtain that currently, one needs to --enable-debug at the Gecko
toplevel, which turns on debug assertions for the entire browser, which
makes things run unreasonably slowly. So it would be desirable to be
able to turn *off* debug mode for the entirety of the browser, but turn
on debug mode for the Rust code only.
Hence this added switch, --enable-rust-debug, which does what it
suggests and defaults to the value of --enable-debug. For our own
sanity and because we judge it a non-existent use case, we do not
support --enable-debug --disable-rust-debug.
Dropped support for python 2.6
Removed support for bookmarks.html
Better internal APIs
Intermediate versions had incompatibilities with old versions
of python 2.7, but 1.2.3 does not.
MozReview-Commit-ID: LfKhr8qWe28
--HG--
extra : rebase_source : 21fc39d45f22f4a6ae10523a87b0e6068f268439
This commit moves symbol dumping to the compile tier, to be run via "syms"
targets. Tracking files are used for the sake of incremental builds, because
dump_syms may genearate multiple outputs whose paths are not known ahead of
time.
Minimal changes to symbolstore.py are made here. More extensive
simplifications will be made in a future commit on the basis of symbolstore.py
handling one file at a time.
MozReview-Commit-ID: 3mOP8A6Y7iM
--HG--
extra : rebase_source : bfe97afcdfc05b9e79f01577701c83e8b00eb4e9
This creates "syms" targets that depend on the corresponding "target" for
directories containing shared libraries or programs. These targets are added
to the main compile graph in automation, and can be invoked through a special
"symbols" target. A future commit will use these targets to dump symbols for
shared libraries and programs during the compile tier.
MozReview-Commit-ID: KLuvmqsK4Zj
--HG--
extra : rebase_source : 8d76b999cb6fac8f11168ac6ebfb58774dfc2d3c
These variables are ignored in favour or reading the same values
from the passed in libdef object.
MozReview-Commit-ID: 8Xkkd68clNN
--HG--
extra : rebase_source : 767c15f1b59a6f48d09411c4f2e64eff9f8b4cc6
When downloading rust manually, it's mandatory to restart the shell,
as the script does not export the PATH environment variable.
This fix also ensures that the rust version in PATH is modern enough for a successful build.
MozReview-Commit-ID: HdLpiLPBLW7
--HG--
extra : rebase_source : dc087c36e89fd6d2957fd1e03af42229de914d5a
This adds a unit test for the expected behavior, and adds the modules
from mach_bootstrap.py that are missing in the virtualenv for the test
to run.
--HG--
extra : rebase_source : e34d0474cfb6c8c5ce9cd847b96de88906191923
In most cases, the HTTP response for the download will contain the
content-length, but if some error happens (e.g. authentication error),
there might not be one, and the download fails with a TypeError for a
division by None, instead of failing with a more friendly error message
about the HTTP error.
--HG--
extra : rebase_source : f179142e69c9ca09b05ad2ff942753fd84da6a69
This is the initial support of 'mach repackage', which can take an
existing tarball and create a DMG on either an OSX host or on a Linux
host with cross-OSX tools. Configure is needed in order to find the
tools necessary to create the DMG. On a Linux cross-compiled environment
with tooltool, this can be as simple as:
export MKFSHFS=$topsrcdir/hfsplus-tools/newfs_hfs
export DMG_TOOL=$topsrcdir/dmg/dmg
export HFS_TOOL=$topsrcdir/dmg/hfsplus
ac_add_options --disable-compile-environment
MozReview-Commit-ID: 6t2rlXpwUvu
--HG--
extra : rebase_source : 39f2f9ecac9d7e5af197f1b5dea70cd307acf488
In bug 1335309, FileFinder was made to default to not find executables,
and zip.py was made to use the default instead. Which made sense for
most uses of zip.py, except for the jsshell package.
So we add a flag to make zip.py able to strip executable (which happens
when the FileFinder is made to find them), and use that flag for the
jsshell package only.
--HG--
extra : rebase_source : 0202f9acd5e6175d3790aaef026e18c6913cf0c6
EmptyConfig objects set JS_STANDALONE=1 by default. However, test tasks that need to run without an objdir
need to be behind an "if not CONFIG['JS_STANDALONE']" condition to avoid causing bustage to sm-pkg task (js
packaging). This patch explicitly deletes that default value, only when generating the TestManifestBackend.
Ideally, the js/src packaging should have their own moz.build instead of re-using the root moz.build. But this
is an easier fix in the short term to get the marionette-harness tests working again.
MozReview-Commit-ID: 26lHLY6WlZK
--HG--
extra : rebase_source : 9c2ffdd938f2f2d6ead7d2aead610a7028e18d97
Because test_objects was a generator, using it in the condition always returned True,
even if no tests were found. But extending test_objects to the manifest, converts it
to a list. So this patch simply moves the 'no tests' check a bit later on.
MozReview-Commit-ID: JpETWD1WQWH
--HG--
extra : rebase_source : 874d7a17d4dfa4a9de4f9daf54b51d1763d55044
This formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 22382e3d65ce8454a1682cfced0d03477762e8fe
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 formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 16ed70edd38a53c3279d8632d7cba3df4d5216c3
The "unsupported code directive" is added to the 'ccache -s' output in
b6d7cf5502
We need to teach our parser for it.
MozReview-Commit-ID: IrrJv7I7BVa
--HG--
extra : rebase_source : 025167f75ce8486287d408ccdb3d8113450354cb
The "unsupported code directive" is added to the 'ccache -s' output in
b6d7cf5502
We need to teach our parser for it.
MozReview-Commit-ID: IrrJv7I7BVa
--HG--
extra : rebase_source : b3bb6de344e26e7a62fc59f899c45168bafca4ef
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
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
Ideally, it would have been better if it were "or", but it's not
possible to override "or" in python ; __or__ is for "|".
This does feel magic, but it's also shorter than adding something like
@depends_any(), and while we're only adding "|" as of this change, we
can add other operations such as "&" in the future, or __getattr__ for
things like milestone.is_nightly.
An alternative form in moz.configure could require the @depends function
to be called, e.g. "a() | b()" instead of "a | b", but I'm not
particularly convinced that one is less magic than the other.
This feature is hooked up such that b is not resolved if a is true,
although in practice, it will still be resolved in Sandbox.run... but
not when --help is passed. In the long run, the forced resolution of
@depends functions will be removed from Sandbox.run.
--HG--
extra : rebase_source : 2389153acfbc3930786d5495ba4a04640325613e
Adding those dependencies, retrospectively, only worked around the poor
handling of --help requirements by the linter, that we fixed a few
commits ago. This is now not necessary anymore.
--HG--
extra : rebase_source : 0ba95ab2d246315be097fed7897db1c20666060a
Several things were wrong with the wrapping:
- the equality test on functions was actually comparing the memoized
functions, which have a type memoize, which inherits from dict. So
they weren't comparing actual functions, but the dict used to store
the cache of their invocation.
- each CombinedDependsFunction created for the same combination function
used a different wrapped function, so even if the dict problem wasn't
there, the equality test still wouldn't work, except if the function
wrapping itself was memoized.
- the memoization was not particularly useful.
Also, for upcoming changes, we'd actually like the combination function to
take an iterable instead of a variable argument list, so that items of
the iterable can be skipped.
--HG--
extra : rebase_source : 2c91889315b49695a2e2b709a9264de9ff237598
We're going to change the function signature for CombinedDependsFunction,
so make it visible in the API that the function member is not meant to
be used directly. The linter still does, though, because it needs to
look in their guts.
At the same time, avoid setting DependsFunction names via the function
name itself, because in upcoming changes, it will not be modifiable in
some cases.
--HG--
extra : rebase_source : a46ec8d3d2e2511dbb44a48cf2c02ab7ad190510
Options with a `when` argument (either directly, or inherited through
only_when() or an include) require --help per _value_for_option, but
that code path is not exercised during a lint pass.
With this change, along the previous one, we now correctly detect that
bug 1316957 was not supposed to work as is.
--HG--
extra : rebase_source : 0961c132bb200a90814b948aff7d2e80a1b21a30
Bug 1313306 relaxed the --help dependency requirement in some cases, but
while doing so, the requirement was also removed in other, unexpected
cases. Specifically, the --help dependency ended up not being required
on indirect dependencies that should have had it, had the --help
dependency been explicit on the direct dependency.
--HG--
extra : rebase_source : 81755988754798590482dfb297b7ddfc14ee88c7
It turns out there are shockingly few cases of manifestparser manifests that actually use the ';'
character as a comment. Because we will soon allow inline comments, deprecating the use of ';' will
ensure that values are allowed to have semicolons in them.
Even without inline comments, might as well enforce consistency across manifests.
MozReview-Commit-ID: AEPPQFdNXG0
--HG--
extra : rebase_source : 3540fa385f328bffb020c0a6debc4d2b3a90ed39
This is an educated guess in an attempt to solve a hard to reproduce intermittent. This
also makes sure the original SIGINT handler is restored after running the linters.
MozReview-Commit-ID: HRo0GRlSN5L
--HG--
extra : rebase_source : 7b8bf4b5818d741b5ab6a38c8c56f4eb53a801c8
If we have rustup installed, use it to check the available
target platforms and install 32-bit windows support if we're
on the (default 64-bit) windows platform.
This catches systems where the mozillabuild bootstrapper was
run before it installed this, so rustup is available, but the
i686 target library isn't.
MozReview-Commit-ID: 9bE2OQnmvxs
--HG--
extra : rebase_source : 0915fef85755718c5524b13b6b7d0d8b6dbe05b4
Windows devs often want to target 32-bit windows. Make this
easier by installing the target for them at mozboot time.
MozReview-Commit-ID: 6gFbFBOqMz8
--HG--
extra : rebase_source : 12933c6cb7895cef859c9022efa87c62f321219e
