We don't really care to set those in js/src/configure because the JS
engine doesn't use ObjC. We also don't care to preserve the += behavior
because there were no AC_SUBST in the first place, so it's unlikely
anyone has an override in their mozconfig and expects it to work.
FasterMake needs some RecursiveMake install manifests to have been
processed before doing its work, so we can actually end up processing
them twice because of the going back and forth from FasterMake in the
hybrid build system.
Set the dependency at the RecursiveMake level when doing an hybrid
build.
Recent changes in bug 1239217 added the faster backend to the default
build mechanism for artifact builds. This seems to have uncovered a
difference in behavior between GNU Make 3.81 and newer. Starting with
GNU Make 3.82, pattern rules are selected according to shortest stem.
Before, they are used in definition order.
So, we change the order of the pattern rules so the longest prefixes are
first. This should result in the same behavior on various GNU Make
implementations.
The current rule is only for "backend.RecursiveMakeBackend", but, with
the current default of generating both the RecursiveMake and FasterMake
backends, the command creates/refreshes both backends. This is, in fact,
how the FasterMake backend is refreshed in most cases.
Moreover, with an hybrid backends, the generated file is not
"backend.RecursiveMakeBackend" anymore, so we need a more generic way to
handle this.
Furthermore, it's not necessarily desirable for all backends to have a
dependency file to handle the dependencies to refresh the backend, so
generate a plain list instead. This has the side effect of making `mach
build-backend --diff` more readable for changes to that file.
Finally, make the backend.* files created like any other backend file,
such that its diff appears in the `mach build-backend --diff` output.
The FasterMake build system is meant to be invoked through `mach build
faster`, which does it already, or, in the near future, as part of an
hybrid build system, which will deal with it as well. People doing
`make -C objdir/faster` won't have the backend automatically refreshed,
but that's not a supported way to use it anyways.
While it would be possible to move those things in the export tier, it
is still interesting to have reporting for them separately, especially
considering I expect things to gradually move from the other tiers to
this new one.
While not entirely obvious, the recurse_pre-export target doesn't imply
actual recursion as long as the RecursiveMake backend doesn't emit
traversal information for it, so nothing will actually happen on this
target, but the interesting part is that it runs, per the generic
config/recurse.mk rules for tiers, between BUILDSTATUS TIER_START and
BUILDSTATUS TIER_FINISH, so that all its dependencies are accounted
as being part of the pre-export tier.
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.
Turns out the claim in bug 1234439 that the FasterMake backend knows
about all the chrome manifest entries is wrong, and there's still one
that is added "manually" with buildlist.py, and during mach build
faster, that can happen before or after the corresponding chrome
manifests are written out by install manifest processing.
While the real fix here would be to make the build system totally
aware of those "manifest interfaces.manifest" entries, for now, it's
simpler to add dependencies to work around the race condition.
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.
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.
While here, use shell_quote instead of manual quoting for those paths.
This might seem like going in the opposite direction of what we tend to do
to move to moz.build land, but those flags are irrelevant in many situations
and are better separated out.
MOZ_DEBUG_DEFINES are essentially defines used everywhere. So treat them as
feeding the initial value for DEFINES in each moz.build sandbox. This allows
the kind overrides that was done in the past by resetting MOZ_DEBUG_DEFINES
in Makefiles.
The only affected symbols are
_PR_<architecture>_Atomic{Decrement,Set,Add,Increment}, they are not exposed in
public headers, have a different name on each architecture, and have a public
API: PR_Atomic{Decrement,Set,Add,Increment}.
Currently, one needs to define DEFFILE or LD_VERSION_SCRIPT appropriately,
and somehow deal with the fact that their input format is different, which
currently relies on manual invocations of the convert_def_file script, with
awkward aggregations.
This simplifies the problem by using a simple list of symbols, with
preprocessing, allowing #includes.
Currently, only css files added through jar manifests are treated this way.
There is really no reason for the discrepancy, but there are actually no css
files added directly through moz.build, so this was never a problem.
On the other hand, it makes things simpler in a world where jar manifests are
treated as if they were entirely described in moz.build (which is where the
FasterMake backend is heading).
Using TEST_DIRS is nothing more than a shortcut for
if CONFIG['ENABLE_TESTS']:
DIRS += [...]
As such, we might as well remove it being a separate variable, and use some
Context magic to just fill DIRS when ENABLE_TESTS is set.
The security/manager/ssl/tests/unit/moz.build change ensures that the order
of DIRS before the change is kept, not because it matters, but because it
allows to confirm that nothing else is modified by this change.
Bug 1191230 added override lines with # characters to chrome manifests
for Windows.
So far, chrome manifests were handled with buildlist.py like in the
RecursiveMake backend, fed with Make variables. Without proper quoting,
those Make variables are just truncated by Make on the first # character,
and this results in mach build faster failing because of that.
However, the reason why chrome manifests were handled with buildlist.py
originally is that not all chrome manifest entries were known to the
FasterMake backend, but they now all are.
So instead of relying on Make variables and buildlist.py, we can now
rely on the newly added install manifests feature allowing to create files
with a given content.
