On Sun, Oct 18, 2015 at 3:18 PM, Nicholas Alexander <nalexan...@mozilla.com> wrote:
> > > 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. > Can you provide some examples that aren't rebuilds of part of the system? I agree that lint and tests are relevant, but that's a different category. -Ekr > 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
