On Mon, Oct 19, 2015 at 11:47 AM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews <j...@joshmatthews.net> > wrote: > > > On 2015-10-19 1:17 AM, Bobby Holley wrote: > > > >> I've heard two compelling arguments against the current setup: > >> (1) It's inconsistent. > >> (2) It causes unnecessary overhead when you do |mach build foo bar| > >> because > >> we link between foo and bar. > >> > > > > I don't recall reading (2) in this thread, and it certainly wasn't the > > case when dumbmake was created. > > > > I was referring to Benoit's point, which admittedly involved two separate > invocations of |mach|. Responding here to a bunch of points because I don't want to write N>1 responses. * The existing build system is a "frankenbuild" because each Makefile is its own DAG / world view and thus can lose dependencies. This is a reason we need to clobber periodically. * `mach build dom/base toolkit/library` is a "partial build" * `mach build binaries` is a "full build" (at least for the Gecko/XUL world view, which is what most readers of dev-platform care about). * "Partial builds" are "frankenbuilds" by definition because you are intentionally skipping dependencies. * "Full builds," while ideal from build system purity perspective, are not always suitable because if you change a highly-used .h file, you could have to wait minutes for all dependencies to rebuild. Sometimes you just want a quick syntax or compilation check in a small set of dependent source files, targets, libraries, etc. * "frankenbuilds" and "partial builds" of today require humans to absorb build system knowledge [in order to work around limitations with "full builds" workflows]. This is not ideal: we would prefer to only expose high-level targets like "binaries" or build modes that take changed files into account to only rebuild a minimal subset (if that's what the developer insists). Also, .h dependency proliferation is a real problem for build system performance, especially with the autogenerated mozilla-include.h (which contains things from every AC_DEFINE in configure.in - an add AC_DEFINE, invalidate everything). If you build the tips of mozilla-central from 24h intervals, you'll find that we pretty much rebuild every Gecko source file due to headers changing. I would encourage a Council of Elrond to somehow tackle this problem. There is preliminary work on a tool in bug 1108293 to help identify dependencies. The last time I showed output to a Gecko developer, there were definitely some WTF reactions. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
