- avoid using py_action with addprefix (process_install_manifest calls)
- use a foreach make loop instead of a shell script for loop (toolkit/components/telemetry)
- pass the directory in which MAKE_PACKAGE should run as an argument instead of changing the directory before calling the macro.
Differential Revision: https://phabricator.services.mozilla.com/D190513
When consuming artifacts from `Bs` jobs, there is no test archive.
The consumer still needs to specify "no tests", but this at least
allows the artifact build to proceed.
Differential Revision: https://phabricator.services.mozilla.com/D136930
None of this is used now that `funsize` generates update MARs. It
might have even been possible to remove this in Bug 1173459, years
ago.
Differential Revision: https://phabricator.services.mozilla.com/D132836
Ever since all builds we get artifacts from have been cross-compiled, those
artifacts have been for Linux. They are not of any use on Mac or Windows hosts,
so it's unnecessary to get them. And we might as well be consistent across
platforms, and not get them on Linux either, even if they are native.
Differential Revision: https://phabricator.services.mozilla.com/D129790
Ever since all builds we get artifacts from have been cross-compiled, those
artifacts have been for Linux. They are not of any use on Mac or Windows hosts,
so it's unnecessary to get them. And we might as well be consistent across
platforms, and not get them on Linux either, even if they are native.
Differential Revision: https://phabricator.services.mozilla.com/D129790
Linux switched to the 3-tier PGO build in bug 1516114, Windows in bug 1557785. These use the 'shippable' platform and the 'pgo' one is not used anymore on these platforms.
Depends on D95802
Differential Revision: https://phabricator.services.mozilla.com/D95803
The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
This is strictly a quality of life improvement when cross-compiling to
Windows targets. A common scenario is mounting an object directory
into a Windows VM, which requires additional VM configuration to
handle (absolute) symlinks. With this patch, `export NSDISTMODE=copy`
in a mozconfig sidesteps any such symlink issues.
Differential Revision: https://phabricator.services.mozilla.com/D77118
This is strictly a quality of life improvement when cross-compiling to
Windows targets. A common scenario is mounting an object directory
into a Windows VM, which requires additional VM configuration to
handle (absolute) symlinks. With this patch, `export NSDISTMODE=copy`
in a mozconfig sidesteps any such symlink issues.
Differential Revision: https://phabricator.services.mozilla.com/D77118
We were using `config.status*` as a catchall in `DIST_GARBAGE` for
`config.status` and `config.statusd`. Unfortunately, the latter was a
directory, so `rm config.status*` error'd out. We can fix this easily
by putting `config.statusd` in `GARBAGE_DIRS`, which will use `rm -r`,
as intended.
Differential Revision: https://phabricator.services.mozilla.com/D64422
--HG--
extra : moz-landing-system : lando
One of these appears to be mistakenly leftover from bug 861178
which was intended to avoid purging dist/, but the code inside the ifndef
no longer does that.
The other is from bug 1246881 to avoid re-writing the buildid.h file
during the profile-use build, but now that there are two separate
builds, they will each have their own buildid.h / source-repo.h files.
Differential Revision: https://phabricator.services.mozilla.com/D56116
--HG--
extra : moz-landing-system : lando
MOZ_1TIER_PGO was a temporary hack to support 1-tier PGO builds while
they were being ported to 3-tier. Now that all builds are 3-tier, it can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D56112
--HG--
extra : moz-landing-system : lando
Local PGO builds now use 3-tier machinery under the hood. Instead of a
single object directory that gets cleaned in between the instrumented
and profile-use builds, now the instrumented build uses a separate
'${objdir}/instrumented' directory. This makes it easier to handle
within mach since we can drive the two builds with environment variables
and keep all build artifacts separate, without needing to do manual
cleanup in between.
Differential Revision: https://phabricator.services.mozilla.com/D50098
--HG--
extra : moz-landing-system : lando
Android artifacts (GeckoView AARs, GeckoViewExample (and Fennec) APKs)
require native libraries (`libxul.so`) and an omnijar (`omni.ja`).
These are produced by `mach package` (really, the `stage-package`
target). Engineers essentially never want a build without a package
for mobile/android. This adds mobile/android-only tiers that run
`mach package` and then `mach android assemble-app`. The latter
consumes `libxul.so` and `omni.ja` to produce _all the things_
relevant to GeckoView engineers.
Differential Revision: https://phabricator.services.mozilla.com/D41450
--HG--
extra : moz-landing-system : lando
Bug 1563711 changed MOZ_FETCHES_DIR to make the MOZ_ANDROID_FAT_AAR_*
environment variables absolute paths. Unfortunately, the replacement
relies on non-osx/windows tasks to run in docker-worker, which is not
necessarily true, and that makes the MOZ_FETCHES_DIR wrong in
non-osx/windows generic-worker tasks. Apparently, that currently works,
but that's not guaranteed to stay this way.
The MOZ_ANDROID_FAT_AAR_* environment variables don't need to be
absolute paths, though. MOZ_FETCHES_DIR is normalized by run-task, and
MOZ_ANDROID_FAT_AAR_* can be set relative to that, which we do here.
Differential Revision: https://phabricator.services.mozilla.com/D40334
At the same time, make things a little more tangible in the tiers setup
in baseconfig.mk.
Differential Revision: https://phabricator.services.mozilla.com/D37942
--HG--
extra : moz-landing-system : lando
Windows 1-tier PGO builds only partially clobber between the
profile-generate and profile-use stages, so that exports/installed files
don't have to be reprocessed. Unfortunately we can't skip the install
manifests in 3-tier PGO because the profile-generate build happens on a
different machine, so we have to differentiate between 1-tier and 3-tier
PGO builds. A new variable, MOZ_1TIER_PGO, is used for this purpose.
Eventually this logic can be cleaned up in bug 1557788 once all PGO
builds use the 3-tier model.
Differential Revision: https://phabricator.services.mozilla.com/D34802
--HG--
extra : moz-landing-system : lando