Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: >> >> Eventually |mach build| should just do the right >> thing, no matter what files you've touched... > > The problem is that definitions of "right thing" differ depending on the > goal, right? I'm using the standard build

Re: Decommissioning "dumbmake"

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

Re: Decommissioning "dumbmake"

On 10/18/2015 10:17 PM, Bobby Holley wrote: On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: On 10/18/15 7:14 PM, Nicholas Nethercote wrote: Eventually |mach build| should just do the right thing, no matter what files you've touched... The problem is that

Re: Decommissioning "dumbmake"

> > 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

Re: Decommissioning "dumbmake"

On Mon, Oct 19, 2015 at 11:47 AM, Bobby Holley wrote: > On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews > wrote: > > > On 2015-10-19 1:17 AM, Bobby Holley wrote: > > > >> I've heard two compelling arguments against the current setup: > >> (1) It's

Re: Decommissioning "dumbmake"

On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews 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| >>

Re: Decommissioning "dumbmake"

On 16/10/2015 08:15, Mike Hommey wrote: > 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++)

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla 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 wrote: >> >>> Hi, >>> >>> I started a thread with the same

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander wrote: > > > On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey wrote: > >> Hi, >> >> I started a thread with the same subject almost two years ago. The >> motivation hasn't changed, but the context surely

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey 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

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > What's needed here is a dependency management system that > simply builds what's needed regardless of what's changed, Otherwise known as "a proper build system". glandium and co. have been working towards that for a long

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:18 PM, Nicholas Alexander wrote: > > > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > >> >> >> On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander < >> nalexan...@mozilla.com> wrote: >> >>> >>> >>> On Thu, Oct 15, 2015 at

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 7:14 PM, Nicholas Nethercote wrote: > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > > > What's needed here is a dependency management system that > > simply builds what's needed regardless of what's changed, > >

Re: Decommissioning "dumbmake"

On Fri, 16 Oct 2015 10:31:43 -0700, Gregory Szorc wrote: > But as awesome as > these targets are, they can still build more than is desired (especially in > the edit .h file case). This slows down iteration cycles and slows down > developers. > > For this reason, I think dumbmake needs to remain

Re: Decommissioning "dumbmake"

On Monday, October 19, 2015 at 11:09:46 AM UTC+11, Eric Rescorla wrote: > On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote > wrote: > > > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > > > > > What's needed here is a dependency management system that > > > simply builds what's

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote: > On 10/18/15 7:14 PM, Nicholas Nethercote wrote: > >> Eventually |mach build| should just do the right >> thing, no matter what files you've touched... >> > > The problem is that definitions of "right thing" differ

Re: Decommissioning "dumbmake"

On 10/18/15 7:14 PM, Nicholas Nethercote wrote: Eventually |mach build| should just do the right thing, no matter what files you've touched... The problem is that definitions of "right thing" differ depending on the goal, right? -Boris ___

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote wrote: > >> not more ways for the user to tell the build system "only rebuild some >> stuff". > > ... except that bholley and ehsan are asking for a way to override the > dependency tracking and just rebuild particular

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote wrote: > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > > > What's needed here is a dependency management system that > > simply builds what's needed regardless of what's changed, > >

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 6:37 PM, Nicholas Nethercote wrote: > On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley > wrote: > > > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 08:43:53PM -0400, Ehsan Akhgari wrote: > On 2015-10-15 8:37 PM, Bobby Holley wrote: > >On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey >> wrote: > > > >On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > >>

Re: Decommissioning "dumbmake"

+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

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > Will building in an arbitrary source directory continue to link libxul? It > was really great when we stopped needing to build in toolkit/library all > the time. The point is, that doesn't reliably happen currently. You should just

Re: Decommissioning "dumbmake"

Also, interactive rebase often dirties a bunch of files unnecessarily - I know they haven't changed, but the build system doesn't. Basically, the best-effort approach of rebuilding directories saves a lot of time for certain Gecko hackers like myself, and it would be really nice if the libxul

Re: Decommissioning "dumbmake"

On 2015-10-15 8:37 PM, Bobby Holley wrote: On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey > wrote: On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > Will building in an arbitrary source directory continue to link libxul? It >

Re: Decommissioning "dumbmake"

On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley wrote: > > |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of

Decommissioning "dumbmake"

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

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey wrote: > On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote: > > Will building in an arbitrary source directory continue to link libxul? > It > > was really great when we stopped needing to build in toolkit/library all > >

Re: Decommissioning "dumbmake"

Will building in an arbitrary source directory continue to link libxul? It was really great when we stopped needing to build in toolkit/library all the time. On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey wrote: > Hi, > > I started a thread with the same subject almost two

Re: Decommissioning "dumbmake"

> |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of the time. Before we had mach, I had an alias for linking libxul. If there is a

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 09:15:01PM -0700, Jonas Sicking wrote: > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are included all over the tree, > > but whose #include-ers generally don't need to be rebuilt all of the time. >

Re: Decommissioning dumbmake

On 15/01/2014 02:37, Matt Brubeck wrote: On 1/13/2014 8:05 PM, Mike Hommey wrote: I hear frontend developers are using it for frontend code, I would like to know if you would be bothered if it were to disappear. As a front-end developer, I think dumbmake is harmful almost as often as it is

Re: Decommissioning dumbmake

(Some messages in this thread seem to be taking an absurdly long time to arrive, so I apologize if what I'm talking about has long been addressed.) On Thu, Jan 16, 2014 at 2:00 PM, Philip Chee philip.c...@gmail.com wrote: On 15/01/2014 02:37, Matt Brubeck wrote: On 1/13/2014 8:05 PM, Mike

Re: Decommissioning dumbmake

On 1/16/2014 11:26 AM, Till Schneidereit wrote: I'd be extremely unhappy if this disappeared without any replacement. Changing a cpp file under js/src and running `mach` takes about 2 minutes for me, whereas running `mach js/src` takes about 18 seconds. As one of the people behind the

Re: Decommissioning dumbmake

On 1/16/14 12:05 PM, Ted Mielczarek wrote: Have you tried `mach build binaries`? That doesn't do the same thing as mach build dirname, though. Certainly not for dom/bindings... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Decommissioning dumbmake

On Thu, Jan 16, 2014 at 6:05 PM, Ted Mielczarek t...@mielczarek.org wrote: On 1/16/2014 11:26 AM, Till Schneidereit wrote: I'd be extremely unhappy if this disappeared without any replacement. Changing a cpp file under js/src and running `mach` takes about 2 minutes for me, whereas