On Mon, 8 Dec 2014 17:51:03 +0100 (CET) Jan Engelhardt <jeng...@inai.de>
wrote:
> On Sat, 28 Jun 2014 18:38:16 +1000, Craig Small wrote in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 :
> >
> >$ cat Makefile.am
> >
> >AUTOMAKE_OPTIONS = subdir-objects
> >bin_PROGRAMS = foo
> >foo_SOURCES = foo.c lib/bar.c lib/bar.h $(top_srcdir)/lib/nothere.c
>
>
> The way I interpret the automake manual is that $() in SOURCES is not
> supported, nor possible. Variables could be changed at make time (by
> passing arguments to make, for example), which provide an instance
> where an ambiguity arises, and automake wants to avoid that :-)
> Second, the value of top_srcdir cannot be known beforehand, because it
> is first set by configure.
>
The opinions expressed in this GNU bug report ---
http://debbugs.gnu.org/db/13/13928.html --- are that Automake's failure
to expand a variable with subdir-objects enabled is a genuine bug.
> The sensible way is to statically resolve $(top_srcdir) with the real
> (relative) path of the source file, that is,
>
> foo_SOURCES = foo.c lib/bar.c lib/bar.h lib/nothere.c
>
> Depending on where your particular Makefile.am is located, it may even
> be ../lib/nothere.c or ../../lib/nothere.c, and so on.
>
>
During out-of-tree builds I have found that replacing $(top_srcdir)/
with the real path (../ in my case) results in build files being created
above the build directory rather than below it whenever subdir-objects
is enabled. In my view Automake ought to place all build files under
the build directory whenever one builds outside of the source tree.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
