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++ with
On Fri, 2011-09-23 at 23:53 +0200, Stephan Bergmann wrote:
My recent commit to start undoing the basis/brand split,
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a66f9903bba9dc7eeff6683ebddcd34d4ad70068
makes it necessary to do clean rebuilds on non-Windows, as the RPATHs of
all
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
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 ?
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
On Mon, 26 Sep 2011 12:49:22 +0100
Caolán McNamara caol...@redhat.com 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
On Mon, 26 Sep 2011 13:43:41 +0100
Caolán McNamara caol...@redhat.com 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
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
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
On Mon, 26 Sep 2011 21:33:03 +0200
Stephan Bergmann sberg...@redhat.com
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
On 09/26/2011 10:01 PM, Bjoern Michaelsen wrote:
On Mon, 26 Sep 2011 21:33:03 +0200
Stephan Bergmannsberg...@redhat.com
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
My recent commit to start undoing the basis/brand split,
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a66f9903bba9dc7eeff6683ebddcd34d4ad70068
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.
12 matches
Mail list logo
