GNU bug report logs - #13928
foo_SOURCES containing unexpanded $(var) breaks with 'subdir-object' option active

Previous Next

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>, automake-patches <at> gnu.org
Cc: Oleg Latin <jujulicca <at> gmail.com>, Diab Jerius <djerius <at> cfa.harvard.edu>, 13928 <at> debbugs.gnu.org, Bert Wesarg <bert.wesarg <at> googlemail.com>
Subject: bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
Date: Sat, 03 Jan 2015 00:23:30 +0100

Hi Eric.

On 01/03/2015 12:14 AM, Eric Blake wrote:
> On 01/02/2015 11:49 AM, Stefano Lattarini wrote:
>> ... even when a source file is specified as '$(srdir)/foo.c' or
>> '$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile
>> fragments (those under '.deps' directories).
>
>> +++ b/NEWS
>
>> @@ -88,6 +88,21 @@ New in 1.16:
>>       using a private target that is only meant to bootstrap the required
>>       makefile fragments.
>>
>> +  - The 'subdir-object' option no longer causes object files corresponding
>> +    to source files specified with an explicit '$(srcdir)' component to be
>> +    placed in the source tree rather than in the build tree.
>> +
>> +    For example, if Makefile.am contains:
>> +
>> +        AUTOMAKE_OPTIONS = subdir-objects
>> +        foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
>> +
>> +    then "make all" will create 'foo.o' and 's/bar.o' $(builddir) rather
>
> s|'s/bar.o'|'s/bar.o' in|
>
Thanks, will fix before merging this in a non-rewindable branch (that
can't happen before Automake 1.16 is released anyway).

>> +    than in $(srcdir), and 'baz.o' in $(top_builddir) rather than in
>> +    $(top_srcdir).
>> +
>> +    This was the second part of automake bug#13928.
>> +
>>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> And thanks for tackling this!
>
Wait to thank me, I've found another pre-existing bug in this area, affecting
non-GNU makes :-/  And by that I mean non-borked ones, like BSD make and
Solaris 10 CCS make.

On the plus side, the bug only affects "make distclean" (causing spurious
failures), and only for packages using a recursive setup and referencing
source files in a parent directory from a subdir Make; so it's a minor one.
On the negative side, I probably introduced it myself in some 1.12.x
release...

Hopefully I'll have a fix in a week or so (I'll be AFK for most time in the
coming days).

Previous Next

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