XPI_NAME affects no tier on its own, as it merely changes paths where
things end up that are defined by other variables.
FILES_PER_UNIFIED_FILE had an erroneous value.
Those are the worst offenders of affected_tiers. The rules to handle
them are all in directories that is not necessarily related to where
the variables are defined, each of which has a Makefile.in for those
rules, which forces export to go through them.
They are respectively using PP_TARGETS and INSTALL_TARGETS. Both affect
the misc tier since bug 1240671, per the *_TARGET value they set in the
backend.
This has the nice side effect of now skipping directories where test
harness files are handled by install manifests.
JAR_MANIFESTS affects the libs tiers through config/rules.mk rules.
While we could move the rules in the backend, they are too complex to
just do that now.
GENERATED_FILES impacts the export tier through the config/rules.mk
definitions, now moved to the backend itself, so that everything is
close to each other.
Those are non-passthru variables with the same property as
ANDROID_GENERATED_RESFILES, ANDROID_APK_NAME and ANDROID_APK_PACKAGE, in
that they don't affect tiers through the backend code itself, but from
the Makefile.in along the moz.build they are defined in.
The are passthru variables that don't actually affect any tier per the
backend itself. They do affect the `export` tier by way of the Makefile.in
along the moz.build defining them, and the existence of those
Makefile.in already guarantees those directories not to be skipped for
`export`.
This initiates a move off affected_tiers in VARIABLES definition to
explicit in-backend handling, which will hopfully make things clearer.
HAS_MISC_RULE is currently used to opt-in to the misc tier in a few
directories with a misc:: rule. It is, in fact, mostly used for custom
xpi creation, which will be separately addressed in bug 1240676, so it
will eventually go away entirely, but in the meantime, we send it as a
throwaway passthru.
Historically, all tiers were handled as opt-out (may_skip), until we
added the first opt-in tier (no_skip). It doesn't make much sense to
differentiate them anymore, so handle them all as opt-in.
When adding a backend, we currently have to add them in three different
places so that they appear in the right places.
Instead, keep the list in a single place.
Currently |./mach artifact| installs an old version of the taskcluster client,
which installs an old version of requests that's incompatible with commonly
installed python versions. This bumps to a version of taskcluster client that
accepts and requests version < 3, so we pick up the in-tree version instead of
installing 2.4.3.
--HG--
extra : rebase_source : 7b4f450c0492fd3c840e4f0a0cce8b42d120df9f
generate_symbols_file only supports the global defines, and completely
ignores DEFINES from the same moz.build the SYMBOLS_FILE is defined.
This fixes this misfeature.
A recent change regressed this behavior -- while an artifact build runs, it
doesn't load certain "about:" pages due to missing libraries in subdirectories
of dist/bin.
--HG--
extra : commitid : HOPgt9kMKoV
AFAICT, we don't actually access web-platform test files from the
objdir for anything except test packaging. And we already have
a mechanism for creating test archives from files directly in the
source directory. So, let's stop copying them to the objdir and
package them directly from the source directory!
The _tests install manifest reports the following change:
before: 41,977 files installed
after: 24,537 files installed
delta: -17,440 files
We still copy some WPT files to the objdir. We might be able to
eliminate these as well. However, since there are only ~200 files,
I'm not too concerned.
I manually compared the resulting web-platform zip archives from before
and after. No files were removed from the archive. However, the new
archive does gain several hundred empty directories with .gitkeep
files. This feels weird, but it shouldn't break anything (I would
think). I'm inclined to leave them for now. I'll file a follow-up
bug to deal with them (preferably by removing them from version
control).
--HG--
extra : rebase_source : d350f8fc223982c8a11a9bf542411e5ec5e44244
The faster make backend cannot support such things, so it's better to
avoid unsupported things to slip in because it happens that doesn't
break what automation runs.
Right now, each incremental build produces a new set of GeckoView
library files, but the previous files don't get cleaned up, and you end
up with a bunch of old libraries in your objdir. This patch cleans up
the old files before producing new ones.
See https://trac.macports.org/ticket/48807. Without it, reading
input can break terminals.
--HG--
extra : rebase_source : 7eab1e60d6a6279fdaf25a4789598cf96e2b8d6c
Also fix that the default merge dir in the mach command creates a directory
that's the merge make target, and thus keeps that make target from actually
running.
--HG--
extra : transplant_source : R%FE%7Eo%CDS%D1%B4%EA%DB%D0%19q%F92%A1V%91%10%5C
Collecting the list of object files compiled, while not ideal, will give us
some indication of how much work was involved in the build. This will help
with analyzing the data.
--HG--
extra : rebase_source : e9861ed5c0766e3ee8038dbec0b9267022c523eb
This adds metadata about the local system to resource_usage.json that will
be useful for analysis when we start collecting these results. Some of it
is redundant with data collected for individual tiers, but having it
available at a top level should make analysis easier.
--HG--
extra : rebase_source : 43b2f6335a4de9c7843f75a3461d2871a97b7752
This moves monitor start/end recording so it also occurs for "what"
builds rather than only for full builds.
--HG--
extra : rebase_source : 833c7311ca5ecfe6935e0a160da695acaecbdeeb
Jacek Caban
Mike Hommey
Chris Manchester
Carsten "Tomcat" Book
Panos Astithas
Jim Chen
Gregory Szorc
Wes Kocher
Nick Alexander
Gijs Kruitbosch
Ryan VanderMeulen
Axel Hecht
Axel Hecht
Bryce Van Dyk
Dan Minor