On Fri, Nov 17, 2017 at 1:06 PM, Gregory Szorc <g...@mozilla.com> 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? > Yes. We're a million miles away from autoconf at this point, and trying to pretend we're not holds us back in a million ways. Nick
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
