Re: [Libreoffice] clean rebuilds needed

2011-09-27 Thread Michael Stahl
On 26.09.2011 22:27, Stephan Bergmann wrote: > On 09/26/2011 10:01 PM, Bjoern Michaelsen wrote: >> No need for such theory, as for all practical proposes, there is ccache >> doing exactly that (although with a bit of addition IO). As for finer >> granularity: With the practical reality of C/C++ wi

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Stephan Bergmann
On 09/26/2011 10:01 PM, Bjoern Michaelsen wrote: On Mon, 26 Sep 2011 21:33:03 +0200 Stephan Bergmann wrote: I think its *file based* dependencies that's the problem here -- they are simply not at the right level of granularity. (Then again, I'm not sure there's at all a working theory of makin

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Bjoern Michaelsen
On Mon, 26 Sep 2011 21:33:03 +0200 Stephan Bergmann wrote: > I think its *file based* dependencies that's the problem here -- they > are simply not at the right level of granularity. (Then again, I'm > not sure there's at all a working theory of making arbitrary changes > to your source tree an

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Stephan Bergmann
On 09/26/2011 07:00 PM, Bjoern Michaelsen wrote: The concept of dependencies only get you so far -- the rest is better left to caching (aka ccache). I think its *file based* dependencies that's the problem here -- they are simply not at the right level of granularity. (Then again, I'm not su

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Norbert Thiebaud
Considering that 1/ there are still quite a few module to gbuildified. i.e quite some work to be done involving modification of Makefiles. 2/ tinderboxes don't suffer from that problem because they typically always do full clean rebuild, and therefore provide a hint as to whether or not a problem

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Bjoern Michaelsen
On Mon, 26 Sep 2011 13:43:41 +0100 Caolán McNamara wrote: > I suppose we'd always be stuck with on incremental builds with e.g. > header removals where the header remains in the solver, and/or a .so > to .a changes, where the .so remain behind. Well, those cases might be solvable actually: gbuil

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Bjoern Michaelsen
On Mon, 26 Sep 2011 12:49:22 +0100 Caolán McNamara wrote: > I *suppose* it would be madness to have dependency rules on the > makefiles themselves that anything created by the makefiles is out of > date when the makefiles change ? *In theory* that would be roughly possible with gbuild because th

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Noel Grandin
That's going to make it painful for makefile hackers, since every time you change the makefile, it will run a "make clean" command. Not saying you shouldn't do it, just that you might need a disable flag for this behaviour. -- Noel Grandin Michael Meeks wrote: > On Mon, 2011-09-26 at 12:49 +0

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Caolán McNamara
On Mon, 2011-09-26 at 13:30 +0100, Michael Meeks wrote: > On Mon, 2011-09-26 at 12:49 +0100, Caolán McNamara wrote: > > I *suppose* it would be madness to have dependency rules on the > > makefiles themselves that anything created by the makefiles is out of > > date when the makefiles change ? > >

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Michael Meeks
On Mon, 2011-09-26 at 12:49 +0100, Caolán McNamara wrote: > I *suppose* it would be madness to have dependency rules on the > makefiles themselves that anything created by the makefiles is out of > date when the makefiles change ? :-) sounds reasonable enough. Of course its more than the

Re: [Libreoffice] clean rebuilds needed

2011-09-26 Thread Caolán McNamara
On Fri, 2011-09-23 at 23:53 +0200, Stephan Bergmann wrote: > My recent commit to start undoing the basis/brand split, > > > makes it necessary to do clean rebuilds on non-Windows, as the RPATHs of

[Libreoffice] clean rebuilds needed

2011-09-23 Thread Stephan Bergmann
My recent commit to start undoing the basis/brand split, makes it necessary to do clean rebuilds on non-Windows, as the RPATHs of all the moved libs have changed. Sorry for the late notification.