On Fri, Nov 17, 2017 at 01:06:05PM -0800, Gregory Szorc wrote: > As I'm working to remove client.mk, I'm encountering quite the spiderweb of > dependencies between: > > * mach > * client.mk > * configure.in and configure > * moz.configure / configure.py > * config.status > * build backend (Makefile.in, etc) > > Today, it is possible to bypass our frontends (mach and client.mk) and > invoke the underlying components (configure, moz.configure, Makefile) > directly. This results in hacks like configure.in being both a valid shell > and m4 file. (The build system copies it to configure but you can also run > `autoconf` to achieve a similar result.) > > While my work to remove client.mk is centered around eliminating the > redundancy between `mach` and client.mk by effectively moving logic into > mach, as I'm touching the code it is obvious that all the code around > configure[.in], moz.configure, config.status, etc could use a major > overhaul. I'd love to say that "`mach` is the only supported interface to > build Firefox." After all, from my perspective as a build system > maintainer, it is much, much easier to support 1 thing instead of N>1. > > This poses the question: is it important to preserve the illusion that our > build system is following autotools "standards"? If not, can we declare > `mach` is the only supported interface and [re]move things like configure.in, > configure, configure.py, config.status, and Makefile.in at our leisure?
I'd rather preserve the configure && make way of building things, but I'll note that the only reason we still have configure.in is only partially because of that. The real problem is that if you add configure to the repository, hg update fails because of the configure file already in the working tree. Yes, the problem would not exist if the file had a different name. That said, now that I think about it from a different perspective, we could do this in a few steps to avoid disruption for most people that update their tree frequently enough: - Step 1: Make client.mk (or whatever replaces it) create and use a different file name *and* remove the configure file. - Step 2, few days/weeks later: rename configure.in to configure. As for the reason configure.in can still be "parsed" by autoconf? Because until recently we still had buildbot jobs that ran autoconf manually from out-of-tree scripts. Mike _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
