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
Before, we checked if config.status was stale in any entrant Makefile
(top level or child directory). This had undesirable side-effects for
partial tree builds, notably that if the build backend was out of date,
the current Makefile was invalidated.
With this patch, we only regenerate the build config automatically in
full/toplevel builds. If an outdated build config is detected on partial
tree builds, we error. The impact of this is mitigated by having mach
build automatically ensure the build config is current.
--HG--
extra : rebase_source : a3a2c1d2bf68d1c0727352ebd9bfb785654e45bf
The existing tier traversal logic is only used in the top-level Makefile
but was present in rules.mk. This meant it was getting evaluated for
every Makefile. This was silly and thus the logic has mostly been moved into
its own .mk file and is only included for the root Makefile.
One of the first actions an invoked Makefile now does is check to see if
*any* moz.build file or Makefile.in is out of date. If so, config.status
is executed to rebuild the build backend.
Since we always perform this check as part of a build, we no longer need
special handling for out of date moz.build files during traversals. This
results in the removal of a significant amount of code!
Another upside of the change is that if a moz.build file is modified
during building, we don't (potentially) modify the build backend from
under the in-progress build. Thus the only race condition that remains
is if a moz.build is mutated during moz.build reading. This window (a
few seconds) is significantly shorter than the time of a full build
(minutes).
This patch should also enable us to remove empty Makefile.in files
without requiring a clobber.
