On Wed, Sep 16, 2015 at 05:33:44PM +0900, Mike Hommey wrote: > Hi, > > Following is a proposal for short term wins for Firefox front end developers. > > The starting point is that there are too many things to change in the > recursive make build system to allow for something like this to work > properly for many different use cases. This also starts from the fact > that, well, we've kept the recursive make build system use the same > model it's been using for, well, close to 20 years. That model is > flawed, and I thought it was about time to do something about it, while > addressing real needs at the same time. > > My proposal is to start a new build backend from scratch, with the aim > to grow it into a complete solution. Build backend means I'm not talking > about replacing moz.build files with something new. I'm talking about > the build system they're munged into. > > It would initially piggy back on the existing build system, because > there are things that aren't exposed in moz.build yet that are > necessary. It would also, initially, not care about the entire build, > and even less about things that are outside of Firefox (tests, addons, > etc.) or compilation. > > My initial work is this patch: > https://pastebin.mozilla.org/8846539 > > (Note: it requires the patches from bug 1204712, bug 1204719 and bug > 1204715, all landed on mozilla-inbound, as of writing)
Filed bug 1207882 for it. > (...) > > - Extend mach artifact to handle any type of Firefox build (not only > Firefox for Android), and to unpack builds completely (not just .so > files), and doubly (by which I mean, unpacking omni.ja as well, with > the code used by toolkit/mozapps/installer/unpack.py) Filed bug 1207888 and bug 1207890 for this. > > - Extend the build system to allow to apply multiple backends at the > same time. `mach build-backend -b FasterMake` only spends 0.05s on my > machine generating its build system, but still spends 4s that are > already spent during configure to read and analyze moz.build files. > That's also true of other backends, and it would be better to allow > people to add their prefered extra backends to their mozconfig. > (and they all rely on the recursive make backend, so that one can be > kept always on for now). It would also help make some of those extra > backends enabled by default depending on what's built. Filed bug 1207893 and bug 1207897 for this > - Ensure --disable-compile-environment works with all the above, but I > don't think there is actually anything to do for this. As a matter > of fact, I've tested it, and it seems to work well enough (and that > lead me to recently fix bug 1203851) > > - Make mac builds fill dist/Nightly.app directly instead of filling > dist/bin (or fill dist/bin as if it were dist/Nightly.app), because > having to run all of > > https://dxr.mozilla.org/mozilla-central/source/browser/app/Makefile.in?offset=0#95-109 > at the end of every build is a pain point. This would have benefits > for other kinds of builds, too. Let's repurpose bug 934070 for this. Mike _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
