On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander < > nalexan...@mozilla.com> wrote: > >> >> >> On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey <m...@glandium.org> wrote: >> >>> Hi, >>> >>> I started a thread with the same subject almost two years ago. The >>> motivation hasn't changed, but the context surely has, so it's probably >>> time to reconsider. >>> >>> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar" >>> sometimes rebuild in some other directories as well. For example, "mach >>> build gfx" will build gfx, as well as toolkit/library. >>> >>> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will >>> only build gfx/2d. >>> >>> There are however now two build targets that can do the right thing for >>> most use cases: >>> - mach build binaries, which will build C/C++ related things >>> appropriately >>> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non >>> C/C++) (although it skips what doesn't end up in dist/bin) >>> >>> At this point, I think "dumbmake" is more harmful than helpful, and the >>> above two targets should be used instead. Removing "dumbmake" would mean >>> that "mach build foo/bar" would still work, but would stop to "magically" >>> do something else than what was requested (or fail to do that thing for >>> all the cases it doesn't know about). >>> >>> Are there still objections to go forward, within the new context? >>> >> >> I agree that dumbmake is more harmful than helpful. I did some of the >> work to port it forward to the mach world; IIRC, my motivation was to ease >> the transition to "mach and smarter build targets". We're now seeing >> smarter build targets that aren't based on (recursive) Make, and dumbmake >> hasn't helped anybody transition to anything: there have been a wopping 10 >> commits to the underlying dependency tree [1], some of which are backouts >> and relandings. >> >> If we need smarter build targets, let's make that happen at the mach >> level, not at the Make level >> > > Slightly off-topic, but I'd like to argue against smarter build targets, > if by that you mean more stuff like "mach build binaries" > > What's needed here is a dependency management system that > simply builds what's needed regardless of what's changed, not more > ways for the user to tell the build system "only rebuild some stuff". > In general, I agree, but there are legitimate differences in user intention that do need to be capture somewhere. I claim that should be at the mach command level, but I don't really care if those are top-level (mach rebuild-xul) or subcommand level (mach build xul), and whether they are internally "smarter build targets". In Android land, we're using Gradle to task switch like this -- build, yes; but also lint; and also run tests; etc. Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
