On 2017/11/18 6:29, Tom Prince wrote:
It would be nice if the entry points that comm-central's buildbot
configuration continued working until after 59 branches. I am planning
to not use buildbot for the 59 release, but I'd like to have buildbot
still working as a fallback.
I'm not sure exactly what interfaces it is using, but I can do some work
to figure it out. Off-hand, I know it at least calls `./configure` and
calls `make` in the objdir. These happen via the `client.mk
<http://client.mk>` in comm-central, directly in the buildbot configs
and in various scripts in the build-tools repo.
I am, like Tom, contributing C-C patches, and I have a nagging feeling
that if client.mk and configure disappears, something bad may happen.
But, right now it is a feeling only.
I suspect C-C developers will notice the bust caused by the new change
first.
On Fri, Nov 17, 2017 at 2:06 PM Gregory Szorc <g...@mozilla.com
<mailto:g...@mozilla.com>> wrote:
As I'm working to remove client.mk <http://client.mk>, I'm
encountering quite the spiderweb of dependencies between:
* mach
* client.mk <http://client.mk>
* configure.in <http://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
<http://client.mk>) and invoke the underlying components (configure,
moz.configure, Makefile) directly. This results in hacks like
configure.in <http://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 <http://client.mk> is centered
around eliminating the redundancy between `mach` and client.mk
<http://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 <http://configure.in>, configure,
configure.py, config.status, and Makefile.in at our leisure?
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org <mailto:dev-builds@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-builds
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
