Re: [PATCH] gnumakefile: better interaction with Automake-NG

[Jim Meyering]

Stefano Lattarini wrote:
> On 08/03/2012 10:14 AM, Stefano Lattarini wrote:
>> On 08/02/2012 07:49 PM, Eric Blake wrote:
>>> On 08/02/2012 11:00 AM, Eric Blake wrote:
>>>> On 08/02/2012 10:53 AM, Stefano Lattarini wrote:
>>>>> * modules/gnumakefile [Makefile.am]: The makefiles generated by
>>>>> Automake-NG always contain a definition of VPATH, even in non-VPATH
>>>>> builds (its value being simply '.' in that case).  So, in the
>>>>> 'clean-GNUmakefile' rule, to determine whether running under a
>>>>> VPATH setup, compare '$(srcdir)' to '.' rather than checking whether
>>>>> '$(VPATH)' expands to the empty string.
>>>>> ---
>>>>
>>>> That fixes things with automake-ng, but what about with existing automake?
>>>>
>> The above copies an idiom mainline Automake emits in its own Makefiles
>> (when cleaning $(CONFIG_CLEAN_VPATH_FILES)) so I say we're safe :-)
>>
>>>>>  clean-GNUmakefile:
>>>>> - test x'$(VPATH)' != x && rm -f $(top_builddir)/GNUmakefile || :
>>>>> + test '$(srcdir)' = . || rm -f $(top_builddir)/GNUmakefile
>>>>
>>>> That is, shouldn't this really be:
>>>>
>>>> case '$(srcdir)' in
>>>>   .|'') ;;
>>>>   *) rm -f $(top_builddir)/GNUmakefile ;;
>>>> esac
>>>
>>> Or am I misreading things again?  I guess your complaint is that for
>>> in-tree builds, $(VPATH) has changed between empty and '.' depending on
>>> automake version, but that $(srcdir) has always been '.' for both
>>> settings of VPATH.
>>>
>> Exactly.  Changing $(srcdir) in any way would cause major breakages
>> everywhere!
>>
> Ping!
>
> There are other objections, or do I have an ACK?

ACK.  Thanks!