Resolving which build system entry points need to exist

--001a113f64f6499673055e341d04
Content-Type: text/plain; charset="UTF-8"

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?

--001a113f64f6499673055e341d04
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As I&#39;m working to remove <a href=3D"http://client=
..mk">client.mk</a>, I&#39;m encountering quite the spiderweb of dependencie=
s between:</div><div><br></div><div>* mach</div><div>* <a href=3D"http://cl=
ient.mk">client.mk</a></div><div>* <a href=3D"http://configure.in">configur=
e.in</a> and configure<br></div><div>* moz.configure / configure.py<br></di=
v><div>* config.status</div><div>* build backend (Makefile.in, etc)<br></di=
v><div><br></div><div></div><div>Today, it is possible to bypass our fronte=
nds (mach and <a href=3D"http://client.mk">client.mk</a>) and invoke the un=
derlying components (configure, moz.configure, Makefile) directly. This res=
ults in hacks like <a href=3D"http://configure.in">configure.in</a> being b=
oth a valid shell and m4 file. (The build system copies it to configure but=
 you can also run `autoconf` to achieve a similar result.)<br></div><div><b=
r></div><div>While my work to remove <a href=3D"http://client.mk">client.mk=
</a> is centered around eliminating the=20
redundancy between `mach` and <a href=3D"http://client.mk">client.mk</a> by=
 effectively moving logic into
 mach, as I&#39;m touching the code it is obvious that all the code around=
=20
configure[.in], moz.configure, config.status, etc
could use a major overhaul. I&#39;d love to say that &quot;`mach` is the on=
ly supported interface to build Firefox.&quot; After all, from my perspecti=
ve as a build system maintainer, it is much, much easier to support 1 thing=
 instead of N&gt;1.</div><div><br></div><div>This poses the question: is it=
 important to preserve the illusion that our build system is following auto=
tools &quot;standards&quot;? If not, can we declare `mach` is the only supp=
orted interface and [re]move things like <a href=3D"http://configure.in">co=
nfigure.in</a>, configure, configure.py, config.status, and Makefile.in at =
our leisure?<br></div></div>

--001a113f64f6499673055e341d04--
0
Gregory
11/17/2017 9:06:05 PM
mozilla.dev.builds 1719 articles. 0 followers. Post Follow

0 Replies
76 Views

Similar Articles

[PageSpeed] 5

Reply: