bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7884: Yacc and FreeBSD make in VPATH builds


From: Stefano Lattarini
Subject: bug#7884: Yacc and FreeBSD make in VPATH builds
Date: Fri, 21 Jan 2011 22:28:24 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

Hello automakers.

What I'm going to illustrate here is a long-standing bug in automake;
but since I don't see it described in the manual, nor reported in the
GNATS database, making it explicitly registered here in Debbugs won't
hurt IMHO.

-*-*-

Here is a description of the bug.

 1) The package developer declares a Yacc-generated program in the
    Makefile.am:
      bin_PROGRAMS = calc
      cacl_SOURCES = calc.y

 2) From that input, automake can generate rules to create *and distribute*
    the Yacc-derived C file `calc.c'.  This C file is distributed so that
    the user won't need to have a yacc program installed in order to build
    the package.

 3) The user has GNU bison installed on his developement machine, and also
    wants to take advantage of bison-specific features.  So he decides to
    just require GNU bison, knowing that such a decision shouldn't affect
    the end users --  the `calc.c' file will be shipped in the distribution
    tarball, so that those users won't need bison in order to rebuild it.

 4) The developer completes the program, and uses "make dist" to build
    the distribution tarball; a proper, up-to-date copy of the generated
    `calc.c' file will be bundled there.

 4) A FreeBSD user, which doesn't have bison installed, but which has the
    standard BSD yacc available in his PATH, fetch the tarball, and
    attempts a VPATH build of the package:
      $ tar xzvf calc-1.0.tar.gz
      $ cd calc-1.0
      $ mkdir build && cd build
      $ ../configure
      ...
      $ make  # this is FreeBSD make
   
 5) For some reason, FreeBSD make does not see, or decides not to use,
    the `calc.c' file in VPATH (here, `..'), and tries to rebuild it
    in thecurrent directory, obviously using FreeBSD yacc.  Oops.
   
I used to think that this bug was due to the fact that FreeBSD make
never performs a VPATH search for a dependency that has an explicit
rule, as reported also in the autoconf manual, see:
 <http://www.gnu.org/software/autoconf/manual/html_node/Make-Target-Lookup.html>

But digging some more, I realized that the bug is present even when
only suffix rues are involved :-(  (see the minmal testcase attached).

-*-*-

The already-committed (to master) testcase `yacc-dist-nobuild.test'
should provide coverage for the bug.

-*-*-

Proposals for a fix (Note: none of these solutions has been really
attempted by me in practice, and none of them seems particularly
appealing, either):

 - Always create yacc-derived and distributed .c and .h files in
   $(srcdir), and explicitly instruct make to alwsys look fr them
   there at first -- similarly to what is done for info files
   (yuck)

 - Tell the developer to add proper AC_CONFIG_LINKS to configure in
   order to support VPATH builds with FreeBSD make (yuck^2, since
   that means keeping track of renamed files when object-specific
   flags are involved).

 - Make the `parse.c' and `parse.h' rules look for same named files
   in $(srcdir) during a VPATH build, and copy them in $(builddir)
   if they're neweer than `parse.y'.  But then how can distclean be
   made to work in evey situation?

 - Tell that FreeBSD make is not supported in VPATH builds (not
   really a solution, I admit).

-*-*-

Regards,
   Stefano

Attachment: foo.test
Description: application/shellscript


reply via email to

[Prev in Thread] Current Thread [Next in Thread]