On Fri, Nov 17, 2017 at 2:08 PM, Mike Hommey <m...@glandium.org> wrote:
> 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. > I was going to suggest moving everything out of the root directory. That way there are fewer files there to confuse people. But we can obviously only do that if we stop supporting `configure && make`. > > 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. >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
