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

Previous Next

Full log

View this message in rfc822 format

From: Bruno Haible <bruno <at> clisp.org>
To: 33668 <at> debbugs.gnu.org, akim <at> lrde.epita.fr
Subject: bug#33668: 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)]

Previous Next

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