Re: bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
Stefano Lattarini <[email protected]>
| Newsgroups | gmane.comp.sysutils.automake.patches |
|---|---|
| Message-ID | <[email protected]> |
[I once again have to correct myself, sigh]
On 01/03/2015 02:14 AM, Stefano Lattarini wrote:
> On 01/03/2015 12:23 AM, Stefano Lattarini wrote:
>> 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...
>>
Nope, it was pre-existing. And I appear to have found an easy enough
fix for it; I will soon post a patch if the testsuite is happy on BSD
and Solaris.
>> Hopefully I'll have a fix in a week or so (I'll be AFK for most time in the
>> coming days).
> >
> Also, it appears this is causing another new testsuite failure with BSD make.
> The following squash-in diff seems to take care of that:
>
> -*-*-*-
>
> diff --git a/bin/automake.in b/bin/automake.in
> index f4327fc..0c44703 100644
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -1677,12 +1677,15 @@ sub handle_single_transform
> {
> $this_obj_ext = $obj;
> $derived_source = 0;
> - # Don't ever place built object files in $(srcdir), even when
> - # sources are specified explicitly as (say) '$(srcdir)/foo.c'
> - # or '$(top_srcdir)/foo.c'. See automake bug#13928.
> - my @d = split '/', $directory;
> - if (@d)
> + do
> {
> + last unless option 'subdir-objects';
> + # Don't ever place built object files in $(srcdir),
> + # even when sources are specified explicitly as (say)
> + # '$(srcdir)/foo.c' or '$(top_srcdir)/foo.c'.
> + # See automake bug#13928.
> + my @d = split '/', $directory;
> + last unless @d;
> my $d = $d[0];
> if ($d eq '$(srcdir)' or $d eq '${srcdir}')
> {
> @@ -1690,7 +1693,7 @@ sub handle_single_transform
> }
> elsif ($d eq '$(top_srcdir)' or $d eq '${top_srcdir}')
> {
> - $d[0] = '$(top_builddir)';
> + $d[0] = '$(top_builddir)';
> }
> $directory = join '/', @d;
> }
>
> -*-*-*-
>
This change was serious bugged BTW. I've now fixed it, but rather than
posting another squash-in, I will re-post the whole adjust patch series
once I've made sure there are no regressions on an of the UNIX flavors
I can test with (GNU/Linux, Solaris 10, AIX 7.1, NetBSD 5.1, FreeBSD 8.0)
Regards,
Stefano