This adds a new `post_build` step to each `BuildBackend`
implementation, and uses it to write .purgecaches after every |mach
build| invocation -- including after |mach build TARGET| invocations.
This approach should be more robust than the existing recursive-Make
based solution, which seems to not write the .purgecaches files in
some situations.
In addition, the recursive-Make solution does not generalize to other
backends, in particular Tup. It is possible that the Tup backend will
handle writing the .purgecaches sentinel as part of its regular build
process, but discussions with mshal suggest that there's no convenient
way for Tup to write .purgecaches only when something *changes* during
the build. That is, Tup can achieve the behaviour implemented by this
patch, but it's not easier to do better by not writing .purgecaches
when the caches do not in fact need to be purged.
I elected to bake in the special knowledge of
--enable-application=browser and macOS here since this whole process
is special. If we need to generalize, we could add a moz.configure
option specifying the purgecaches directories, but it doesn't seem
worth it right now.
The ideal approach would be to determine FINAL_TARGET from the
application directory, but that is determined by DIST_SUBDIR. In
addition, it's not clear how to present that information to the
post-build step in a build-backend agnostic manner.
This will require tweaking as we migrate the macOS bundle handling to
moz.build, especially in browser/app. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1223748, which could
improve this significantly.
MozReview-Commit-ID: 63KZy18D23i
--HG--
extra : rebase_source : c5f75192f1b77f08611662f51caa92dcb1ca802f
Right now, we only expect classes.dex, and even --with-gradle we copy
it out of $topobjdir/mobile/android/base. This commit changes that
for --with-gradle: we only take classes.dex from the given .ap_ file,
and we also handle multiple classesN.dex files (for future multi-dex
support). The moz.build system stays the same.
This avoids an issue with newer Android-Gradle plugins, where the
classes.dex produced could be either in dex/ or in dexMerger/,
depending on whether any external libraries needed merging. By
extracting classes.dex from the .ap_ file, we don't need to know what
Gradle build steps actually occur.
The classes.dex in the package-manifest.in has been irrelevant since
Bug 1260241.
MozReview-Commit-ID: FozKwjTcMzU
--HG--
extra : rebase_source : 62b18c7ffe596be73cec4c9565333eac222b018e
There's a bug in InstallManifest::add_entries_from: some of the
manifest entries bake their destination into both the manifest key and
the manifest value, and add_entries_from with a non-empty "base"
parameter to prepend to the destination only updates the manifest key
and not the value.
This bug causes |mach watch| to fail to _read_ the unified manifest
that aggregates all of the build manifests relevant to |mach watch|
that |mach build-backend -b FasterMake| successfully _wrote_, because
the manifest keys are validated against the manifest values written to
disk.
I see no way to address this other than to manually reach into the
manifest values and patch the internal destination parameter, which
this patch does.
MozReview-Commit-ID: FVyRB41NnHa
--HG--
extra : rebase_source : 23eb18ddc0452955539ce2e7a6d7bbfd083c940c
This is a bustage fix that needs to get out quickly. Once landed we can take
the time to enable it on more directories, or preferably change it to a
blacklist.
MozReview-Commit-ID: Gbf7q2L0tg3
--HG--
extra : rebase_source : a58ae64c655b24e686710a663d4538b4cfe020f7
Firefox generally supports the same range of LLVM versions as Mesa.
Instead of regularly updating it just pull Mesa drivers which will
be required by WebRender, anyway.
MozReview-Commit-ID: DiK4TD9tWe0
--HG--
extra : rebase_source : 5dd9c8c46ae79deee8f2fd887b27fddbc30fc22d
The initial motivation for this patch, was to prevent command lines that are
too long on Windows. To that end, there is a cap to the number of paths that
can be run per job. For now that cap is set to 50. This will allow for an
average path length of 160 characters, which should be sufficient with room to
spare.
But another big benefit of this patch is that we are running more things in
parallel. Previously, mozlint ran each linter in its own subprocess, but that's
it. If running eslint is 90% of the work, it'll still only get a single
process. This means we are wasting cores as soon as the other linters are
finished.
This patch chunks the number of specified paths such that there will be N*L
jobs where 'N' is the number of cores and 'L' is the number of linters. This
means even when there's a dominant linter, we'll be making better use of our
resources. This isn't perfect of course, as some paths might contain a small
number of files, and some will contain a very large number of files. But it's
a start
A limitation to this approach is that if there are fewer paths specified than
there are cores, we won't schedule enough jobs per linter to use those extra
cores. One idea might be to expand specified directories and individually list
all the paths under the directory. But this has some hairy edge cases that
would be tough to catch. Doing this in a non-hacky way would also require a
medium scale refactor.
So I propose further parallelization efforts be destined for follow-ups.
MozReview-Commit-ID: JRRu13AFaii
--HG--
extra : rebase_source : 242fb71fe0af8bd2a981bd10a7216bb897fe00ac
Downstream npm package already depends node package, no need to
specify it explicitly. Also, node package refers to the latest NodeJS
but npm package can be built against an older version.
MozReview-Commit-ID: KeuSFEKeStw
--HG--
extra : rebase_source : ac3ab14519f4edd8bcb5b77cad64eeaed16d2751
Have `./mach boostrap` update users to at least rust 1.23.0,
which is the current stable release.
MozReview-Commit-ID: 7ukx7shu07e
--HG--
extra : rebase_source : 82ea7fd65901f0e9e00e961d157cf113d82b1d4e
Back when the mach artifact toolchain code was written, there was no
official way to get a default set of parameters for taskgraph
generation. As of bug 1401199, that is not true anymore, so we can now
use that instead of manually set parameters and hope that doesn't break,
which happened with bug 1430823. This change should make things more
future proof.
This also reverts the changes from changeset 3a8491857651, which fixed
the same issue in a slightly different way.
--HG--
extra : rebase_source : 188446bf254551b9e7b98d51735e3026b835e76d
And remove the two cases that currently set that, without actually using
it. The webrtc gtest one never relied on it, and the gfx one was added
in bug 1427668 for a single header, and the corresponding #includes were
changed in bug 1428678.
--HG--
extra : rebase_source : ebb3aed6ff8e3438d4a2f011725cf1a15986fee6
This fixes a regression in 195e88aab631 (bug 1429094).
When I reviewed that changeset, I didn't realize there were callers
of the renamed function outside the file.
The other caller (changed in this commit) needs to interact with the
repository. This may require loading extensions. So we can no longer
unconditionally disable the loading of hgrc. We add an argument to
control the loading of hgrc to support this.
MozReview-Commit-ID: 8AkPhvtC1VH
--HG--
extra : rebase_source : b2bf3dcc52ac6bdeb86ea56923b9eaea0771739e
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
When bootstraping the development environment on a machine without
rustup installed, download and install rustup version 1.9.0,
released 2018 January 4, instead of the older 1.5.0.
This saves a self-upgrade step in the short term and reduces the
chance of lost support failures in the long term.
MozReview-Commit-ID: H8ouRszLMsP
--HG--
extra : rebase_source : 0eacfff2fa3e21e64dbbc998aee91600f5bb5d68
