lilypond-devel
[Top][All Lists]
Advanced

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

Re: Staging broken.


From: Jonas Hahnfeld
Subject: Re: Staging broken.
Date: Wed, 19 Feb 2020 09:46:15 +0100
User-agent: Evolution 3.34.4

Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
> > > The procedure for a patch would be
> > > 
> > > git apply --index xxxx.diff
> > > ./autogen.sh --noconf
> > > cd build
> > > ../configure --enable-checking  # and/or other desired options
> > > make clean test-clean doc-clean
> > > CPU_COUNT=9 make -j9 # or whatever other options
> > > CPU_COUNT=9 make -j9 check
> > > CPU_COUNT=9 make -j9 doc
> > 
> > In my experience this doesn't work in all cases. I just switched back
> > from branch where I worked on the build system and here's what I get
> > (after running $ autoconf in the src directory):
> >  $ ../src/configure
> > [...]
> > configure: creating ./config.status
> > config.status: creating config.make
> > config.status: creating config.hh
> > config.status: config.hh is unchanged
> >  $ make
> >  *** /code/LilyPond/build/config.hh is out of date
> >  *** Remove it and rerun autogen:
> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
> >  $ make clean
> > [...]
> >  $ make
> >  *** /code/LilyPond/build/config.hh is out of date
> >  *** Remove it and rerun autogen:
> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
> > 
> > As you can see, configure is "clever" and notices that config.hh would
> > not change. So instead of touching it (and forcing a full rebuild), it
> > just keeps the old modification date and our /GNUmakefile.in gets
> > pretty angry about it.
> 
> "Angry" seems like a weird characterization.
> 
> > If I actually remove config.hh and then re-run configure, it obviously
> > works - but I'd consider this a problem in the build system. Also note
> > how the recommendation is wrong in my example as I build in a separate
> > directory...
> 
> If config.hh is "outdated", why not run ./config.status --recheck ?  Can
> we do that?  We'd probably need to call make recursively then so that it
> rereads the regenerated Makefile .

If I understand the situation correctly, ./config.status --recheck
wouldn't touch config.hh either, right? 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.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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