Jonas Hahnfeld <hah...@hahnjo.de> writes: > Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup: >> 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 . > > 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
