On 8/27/2014 6:52 AM, Benjamin Smedberg wrote: > On 8/27/14, 9:47 AM, Gregory Szorc wrote: >> >> I interpret this this use case as building a related set of object >> files for the purpose of quick/imprecise validation of changes to a >> specific component. So what you really want is to build specific >> "modules." Is that accurate? > That sounds like a complex way to phrase it: how about "I changed some > files in toolkit/locales and toolkit/modules and I'm pretty sure there > aren't external dependencies, so I just want to rebuild toolkit/* to see > those changes". > > I've done something similar with "mach build browser/experiments && mach > build browser/locales && mach build toolkit/modules", although I'd > really love that to just be "mach build browser/experiments > browser/locales toolkit/modules".
There is additional cognitive load required to map a logical feature into a set of directories. I would prefer this burden go away, as it only breeds confusion and a higher barrier to contributing (new contributors don't know these shortcuts so they sit through painfully long full builds). I would support additions to moz.build that defined high-level "targets" that mapped to various directories/targets. i.e. we would move aspects of dumbmake into the build system itself, rather than stapled on top of |mach build|. The purist in me doesn't like this - I'd much prefer to have a full DAG that builds instantaneously. But I'm pragmatic about the needs of developers and view |mach build <feature>| as a step in the right direction. Also, for the JS-centric use case you mentioned, if we invested in those parts of the build system, we could probably get full tree builds with no binary changes to under 10s. e.g. |mach build nonbinaries|. At that point, I argue |mach build <feature>| is only marginally useful for non-binaries people and that partial tree build is really only useful for the C/C++/IDL developers so they don't have to sit through many minutes of compiling after they change a widely used header file. However, the non-binaries part of the build hasn't received much love and it's unclear who will work on it. Since we'd have to build |mach build <feature>| for Gecko developers, I guess we could piggyback non-binaries parts onto it for the time being. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
