+++ This bug was initially created as a clone of Bug #848530 +++ Bug 848530 has some holes in it. Notably, RecursiveMakeBackend.built is defined in the root Makefile.in. If we have other projects utilizing rules.mk (like js/src), they won't inherit this rule. We should move that rule to rules.mk. A nice benefit of this is that invocation will be in-lined instead of having to shell out to the root Makefile.

Now I remember why I didn't do this: we need the paths in RecursiveMakeBackend.built.pp to be normalized to absolute paths in order for the include to work from any directory. We can still move the rule to rules.mk. But, we need a make file in the root directory to handle including the .pp unless the paths are absolute. I think it's easier to just normalize topobjdir. So blocking on bug 873325.

This should do it. Tested on OS X and Windows. Sadly, we need a clobber (really a config.status run) otherwise the dependencies in backend.RecursiveMakeBackend.built.pp won't apply properly with the new code. I also added code to track the mozbuild .py files as dependencies. It is a little fragile, but I added an assert to protect us. This means that if we change how the sandbox or backend works, we should automatically get a backend rebuild. This should hopefully significantly reduce the number of clobbers that we need to perform. Invalidation will likely occur more than needed. But it should be cheap and I think this is better than requiring excessive clobbering. Furthermore, I think it is right: we want to rescan moz.build and regen the backend if any of the code touching those systems could change the output. I also added a small change to ConfigStatus.py to normalize another topobjdir path to absolute. This was needed to ensure paths in the generated .pp are always absolute. https://tbpl.mozilla.org/?tree=Try&rev=e5c5055a0634

https://hg.mozilla.org/integration/mozilla-inbound/rev/0931f7400cf2 Thank you for the quick review!