GNU bug report logs - #33668
built-in YACC rule generates file in build dir, not source dir

Previous Next

To reply to this bug, email your comments to 33668 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org, Akim Demaille <akim <at> lrde.epita.fr>
Subject: built-in YACC rule generates file in build dir, not source dir
Date: Fri, 07 Dec 2018 23:39:25 +0100

[Message part 1 (text/plain, inline)]

Hi,

The Automake-generated Makefile rule for .y files, when run in a VPATH
build, produces the generated .c file in the build directory, not in the
source directory.

How to reproduce:
- Unpack the attached hello.tar.gz
$ cd hello
$ ./autogen.sh
$ mkdir vpath
$ cd vpath
$ ../configure
$ make
...

$ ls -l ../rpcalc.c rpcalc.c
ls: cannot access '../rpcalc.c': No such file or directory
-rw-rw-r-- 1 bruno bruno 44704 Dec  7 22:54 rpcalc.c

$ make dist
$ tar tfz hello-0.tar.gz
hello-0/
hello-0/autoclean.sh
hello-0/autogen.sh
hello-0/rpcalc.y
hello-0/rpcalc.c
hello-0/INSTALL
hello-0/Makefile.in
hello-0/aclocal.m4
hello-0/configure.ac
hello-0/configure
hello-0/Makefile.am
hello-0/build-aux/
hello-0/build-aux/ylwrap
hello-0/build-aux/missing
hello-0/build-aux/install-sh
hello-0/build-aux/compile

So, you can see that

  * "make dist" produces a tarball which contains the rpcalc.c file.
    This is good, because yacc or bison is not one of the programs
    that all programmers have preinstalled.

Now, the GNU coding standards say that in this case the rpcalc.c file
should be generated in the source directory:
https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html

  "GNU distributions usually contain some files which are not source files—
   for example, Info files, and the output from Autoconf, Automake, Bison or
   Flex. Since these files normally appear in the source directory, they
   should always appear in the source directory, not in the build directory.
   So Makefile rules to update them should put the updated files in the source
   directory."

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.

As you can see from the 'ls' command above, Automake has generated
it in the build directory. It should generate it in the source directory
instead.

The way to implement this is that the generated Makefile.in should not
have a rule

.y.c:
	$(AM_V_YACC)$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h `echo $@ | $(am__yacc_c2h)` y.output $*.output -- $(YACCCOMPILE)

but instead have a rule

$(srcdir)/rpcalc.c: $(srcdir)/rpcalc.y
	$(AM_V_YACC)$(am__skipyacc) $(SHELL) $(YLWRAP) $(srcdir)/rpcalc.y y.tab.c rpcalc.c y.tab.h rpcalc.h y.output rpcalc.output -- $(YACCCOMPILE) && sed -e 's|".*/rpcalc.y"|"rpcalc.y"|' < rpcalc.c > rpcalc.c-tmp && rm -f rpcalc.c && mv rpcalc.c-tmp $(srcdir)/rpcalc.c

The sed postprocessing is to fix the relative file names in #line statements
in the generated .c file.

Credits: The pattern of this rule comes from Daniel Richard G., Ralf Wildenhues,
and Pádraig Brady. See
https://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00481.html
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=modules/parse-datetime

Bruno

[hello.tar.gz (application/x-compressed-tar, attachment)]

Message #8 received at 33668 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: 33668 <at> debbugs.gnu.org
Subject: Re: bug#33668: built-in YACC rule generates file in build dir, not
 source dir
Date: Sat, 8 Dec 2018 15:42:16 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.