(This is likely off-topic for many dev-platform readers. I was advised
to post here because RelEng monitors dev-platform and I don't like
cross-posting.)
The technical interaction between build automation and mozilla-central
has organically grown into something that's very difficult to maintain
and improve. There is no formal API between automation and
mozilla-central. As a result, we have automation calling into esoteric
or unsupported commands and make targets. Change is difficult because it
must be coordinated with automation changes. Build system maintainers
lack understanding of what is and isn't used in automation. It's
difficult to reproduce what automation does locally.
The current approach slows everyone down, leads to too-frequent breakage
(l10n repacks are a great example), and limits the efficiency of automation.
I'm elated to state that at a meeting earlier today, we worked out a
solution to these problems! Full details are in bug 978211.
tl;dr we are going to marshal all interaction between automation and the
tree through a mach-like in-tree script. This script will establish a
clear, supported, and auditable API for automation tasks and will
establish a level of indirection allowing the tree to change without
requiring corresponding changes to automation.
Some of the benefits of this approach include:
* Abstracting the build backend away from automation. The tree will
choose GNU make, pymake, mozmake, Tup, etc depending on what it knows is
best. Currently, automation has {make, pymake, mozmake} hard-coded.
* Allowing the build system to execute more efficiently. Currently,
automation executes compile, symbol generation, and packaging as
separate steps. This change opens the door to moving all these steps
into the core build system's DAG so they can run concurrently, allowing
your build jobs to complete sooner.
* Better support for l10n repacks. They have been a constant headache
for everyone who's touched them. This opens the door to moving more of
the logic into the tree, in a more well-defined API.
* A lot of us want to kill client.mk. Having automation not directly
calling it will allow us to finally do this.
* Clearer identification of problems and responsibilities. Currently,
when something like l10n repacks break, it's not clear if it was due to
a change in the tree or in automation or even what change caused the
regression! Sadly, lots of fingerpointing and "not my problem" tends to
ensue. This change will establish clearer borders and thus lead to
easier and better resolutions.
Please follow bug 978211 for updates.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
