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: Ralf Wildenhues
Subject: bug#7884: Yacc and FreeBSD make in VPATH builds
Date: Sat, 22 Jan 2011 10:11:15 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* 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





reply via email to

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