Subject: bug#7884: Yacc and FreeBSD make in VPATH builds

From: Ralf Wildenhues <[email-masked]>
Date: Sat, 22 Jan 2011 10:11:15 +0100

* Stefano Lattarini wrote on Fri, Jan 21, 2011 at 10:28:24PM CET:
>  - 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)

Yes, this is ugly, but it is a way that can be made to work.
One complication is that, for portable semantics, if a file is
ever mentioned as $(srcdir)/file as a prerequisite, then it also
needs to be listed that way as a target.  (I think; it might've
been the other way round.)

Downside of this is that now builds fail to work as expected when
there are newer versions of the files in the build tree.  GNU make
users would likely complain.

Still, this could be viable as optional behavior.

>  - 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?

I doubt that these two options can be made to work sanely.  A
  file: $(srcdir)/file

doesn't work with GNU make, for example: it will rightfully complain
about a circular dependency.

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

Why not?  VPATH is not specified by Posix, and there is a reason for
that: behavior is just too variable and different between makes.  This
means that only some setups work well, others don't.

I'm concerned mostly with users downloading stuff: they should be able
to build source packages.  If VPATH doesn't work, that is not a big
problem because they can still use an in-tree build.  It doesn't make
the package unusable for them.

The actual complication, as far as I can see, comes from the fact that
I want VPATH builds to work for the packages I'm interested in.  ;-)

Cheers,
Ralf