Closed Bug 1498031 Opened Last year Closed Last year
Merge code paths for deciding when to run configure between tup and make
46 bytes, text/x-phabricator-request
|Details | Review|
These should already be equivalent because they get their dependencies from the same place. Let's clean up the calling code so we don't have to rely on client.mk for this anymore.
While writing this patch it stops making sense for the make build system to know about config.status at all, including various checks we have that will cause configure to run if config.status is out of date. This could be an issue for people relying on "make" as an entry point to the build system, but I'm going to assume in this patch that while we probably want the entry points "make" and "configure", reducing the lengths a bare "make" invocation will go to ensure configure is up to date is ok.
This addresses a related issue along the way: a build that results in running configure would not update the value of self.config_environment (and therefore self.substs) as seen from the build driver, so out of date values would have been used. The changes to Makefile.in and client.mk made exploit the assumption that by he time anything in the Make build is running, config.status is up to date. Users running "make" without the benefit of "mach" will need to manually run configure when necessary in order to take this into account.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/6dad1580bc3e Merge code paths for running configure between Tup and Make based backends. r=firefox-build-system-reviewers,mshal
You need to log in before you can comment on or make changes to this bug.