Re: Staging broken.

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

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

But after running it we should be fine touching it ourselves.

./config.status --recheck && touch config.hh && $(MAKE) all

Add directory variables as needed.

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

-- 
David Kastrup