On 2/28/14, 1:28 PM, Boris Zbarsky wrote:
On 2/28/14 3:48 PM, Gregory Szorc wrote:
* A lot of us want to kill client.mk. Having automation not directly
calling it will allow us to finally do this.
This will make bisects a bit exciting, because the right command to run
to "do a toplevel build" will depend on the exact revision you have
checked out.
How feasible is keeping client.mk only to the extent that doing "make -f
client.mk" or "make -f client.mk build" does the same thing as "mach
build"?
We could probably keep the default API there (or whatever is needed for
bisects).
FWIW, the new approach will make bisects more robust over the longer
term. Today, all this build logic lives outside of the tree in
automation configs. So, if we change how build/automation works, we just
made it impossible to build earlier revisions in automation. e.g. if I
push Firefox 7 to Try today, it will probably fail to build.
A goal of the new approach is to build automation-compatible backwards
compatibility in from the start so we don't have this problem. That does
rely on other things, such as automation pulling the build environment
(e.g. chroot configuration) from the tree or having some awareness of
which changesets caused which changes. We'll get there eventually.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
