Jonas Hahnfeld <hah...@hahnjo.de> 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
