c04e18fa25
If mozbuild parsing fails due to a missing file (eg: a file not existing in UNIFIED_SOURCES), then no Makefiles are written out, but config.status exists. This would cause mozbuild to think that configure doesn't need to run, and rely on make to perform the backend-out-of-date check in rebuild-backend.mk. Unfortunately since no Makefiles were written, the make command fails immediately and no attempt is made to re-create the backend. Note that this is only a problem if the first mozbuild parsing from a clobber build fails, otherwise there is typically a top-level Makefile from a previous build to call into (at which point make can determine it is out-of-date, and re-invoke itself). The fix is to have the RecursiveMake backend re-use the same logic that was introduced into mozbuild for alternate backends, and remove rebuild-backend.mk. This way, mozbuild can always determine if the backend needs to be regenerated, even if the initial parsing failed. Test code was also relying on rebuild-backend.mk to generate the TestBackend, but moving backend_out_of_date() into MozbuildObject allows this code to be shared. Differential Revision: https://phabricator.services.mozilla.com/D26262
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025