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?
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
