bug#33668: built-in YACC rule generates file in build dir, not source dir

[Hans-Bernhard Bröker]

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