[Accidentally sent this to Bruno only, before...] Am 07.12.2018 um 23:39 schrieb Bruno Haible:
> Why is this important? Because without it, maintainers which ONLY use VPATH > builds on their development machine: > $ mkdir build-42 > $ cd build-42 > $ ../configure CFLAGS="-O0 -ggdb" > ... > $ cd .. > $ rm -rf build-42 > will see the file being regenerated over and over again, each time they > do a fresh build in a new subdirectory. That's not how a well-behaved > build system should behave. > I beg to disagree here. Just because builds are done via VPATH, that doesn't mean they will invariably be nixed after every build --- and those who do that already rebuild just about everything every time round, so a couple YACC runs won't make any noticeable difference. Actually, by the usual arguments for doing it this way, they would _have_ to be rebuilt every time, just like everything else. OTOH, VPATH builds can remain standing and be delta-compiled just like in-tree ones, and one of the reasons that cause maintainers to use VPATH builds involve keeping around different builds, with different tools used, without having to nix everything every time around. That means all output of such tools has to be build-specific, and thus needs to be in the build tree. In the case at hand it can be quite important to check that the project works well with both yacc and bison. That would be impossible with parser.c in the source tree. The same argument holds for checking buildability with both lex and flex, gcc and clang, etc. Texi output is different because there is, for all intents and purposes, only one toolchain in existence to create it, thus no difference to test for/against.
