The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
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.
--HG--
extra : commitid : 7nD60DTsoHz
extra : rebase_source : 61b5803732b0ecdff421e4e15a2086d4eae7a937
extra : amend_source : c0ae62708b2019888ea320c3793d4ea3f6d6d460
For some reason, recent changes with the install-dist/% rules broke the
dummy wrapper used by `mach build faster`, leading to `Nothing to be done
for install-dist_idl.`, subsequently failing to build xpt files because
of the missing idls in dist/idl.
--HG--
extra : commitid : 7SoYbKdAeSQ
extra : rebase_source : 8fee8fdae0d04aed3906d00d33dd7b830f82d75f
extra : amend_source : 2a9a1086d409fbcd4386b7d589c8df50dcdf4b26
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.
Install manifests are not empty in normal conditions, apart a few
exceptions where they are only used for a "magic" `rm -rf`.
However, we're going to introduce changes that will empty some of
the install manifests and make their work happen from a different
backend, in which case we don't want them to correspond to a `rm -rf`.
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.
This change allows specifying objdir-relative paths in EXPORTS to enable
exporting entries from GENERATED_FILES. Objdir paths in EXPORTS that are
not in GENERATED_FILES will raise an exception.
Example:
```
EXPORTS += ['!g.h', 'f.h']
GENERATED_FILES += ['g.h']
```
Given the implementation, this should also work for FINAL_TARGET_FILES,
FINAL_TARGET_PP_FILES, and TESTING_FILES, but those are not well-tested.
This patch also renames the install manifest for '_tests' to match the
directory name for convenience in some code I refactored.
--HG--
extra : commitid : CwayzXtxv1O
extra : rebase_source : 5fb6f461fc740da9bce14bbdbfabdfe618af8803
We have many unit tests in the tree for some small parts of the build system
pipeline, but we don't have anything that resembles an end to end test, and we
kind of rely on the resulting Firefox not being broken by our changes.
With the Faster make backend growing, I want to ensure it produces the same
thing as the recursive make backend, at least for the parts it supports.
This adds some kind of test that allows to check that.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
This change merges mozilla-central and comm-central into having a single
topobjdir file but retaining two topsrcdirs (and two build systems). This state
is hopefully only the first part of a series of changes that eliminate the
comm-central build system partial clone completely.
--HG--
extra : rebase_source : 02aa2c4551df405d9783ac85cc41fe90b67bf057
extra : amend_source : d3cc677d59603648165bf65afa28413f2c40b2fd
- Linux ASAN nightly builds do not do update packaging
- Only set mar properties if the mar file was actually created
- Unset MOZ_SIGN_CMD for pretty-* steps
Before making top-level traverse js/src moz.build files, there was a need to
distinguish between top-level traversing e.g. top-level moz.build or
config/moz.build and js/src traversing them. With a single traversal of both
moz.build sets, we now only need to distinguish between js standalone builds
and gecko builds.
There is still, however, a need to distinguish between top-level vs. js/src
configure runs on gecko builds to make them subconfigure icu and libffi from
top-level instead of js/src in js standalone builds, or when choosing to make
js/src's config.status do something when run or not.
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in
