mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-20 16:55:40 +00:00
4161679514
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 : e973d065cd91e965f4103ed2732858e2e7a9c546 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| l10n/fluent_migrations | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozterm | ||
| mozversioncontrol | ||
| mach_commands.py | ||
| moz.build | ||
| README | ||
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025