Re: Staging broken.

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

-- 
David Kastrup