+1 For my use case breaking dumbmake is preferable given that we now have 'build binaries'. When touching commonly included header I often like to run ./mach build gfx && ./mach build binaries. This effectively let's me say 'Make sure my gfx changes are good before you recompile the rest of gecko' giving me control over the recompile order. This will notify me quickly if there's a compile error without having to rebuild everything that include the header that I changed giving me compile errors much faster. With the current behavior './mach build gfx' will try to link when I haven't yet recompiled all the files that I need.
On Thu, Oct 15, 2015 at 8: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? > > Cheers, > > Mike > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
