lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Staging broken.


From: Han-Wen Nienhuys
Subject: Re: Staging broken.
Date: Wed, 19 Feb 2020 11:47:05 +0100

On Wed, Feb 19, 2020 at 11:06 AM David Kastrup <address@hidden> wrote:

> Han-Wen Nienhuys <address@hidden> writes:
>
> > On Wed, Feb 19, 2020 at 10:03 AM David Kastrup <address@hidden> wrote:
> >
> >>
> >> > So the dependency isn't correctly satisfied and we would always run it
> >> > from then on, effectively slowing down our build system.  And that is
> >> > why I don't want to deal with this kind of issues - this should come
> >> > with the build system for free.
> >>
> >> Well, since we have our own build system, making it come for free is
> >> sort of our own job.
> >>
> >>
> > I think it's easier if we give up on intelligence here, and just
> recommend
> > ccache.
>
> That does not seem like much of a help for the problem case at hand.


Autoconf tries to leave the config.h alone, using content based checks.

I assume it does this because touching config.h triggers an expensive
global recompile in timestamp-based build systems, like make.

Our GNUmakefile tries to detect changes to config.h.in using timestamps,
but autconf (see above) won't overwrite the file unless it really changed,
so the default doesn't do the right thing.

Our comment says:

# this is to prevent people from getting
# undefined symbols  when we add them to config.h.in,
# and they blindly run "cvs update; make".

the mention of CVS shows you how old this comment is.

My proposal is to have configure always regenerate config.h, because
ccache makes the full rebuild almost free, so we don't need configure's
cleverness.

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]