bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefano Lattarini
Subject: Re: [PATCH] gnumakefile: better interaction with Automake-NG
Date: Sat, 04 Aug 2012 16:56:28 +0200

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?

Thanks,
  Stefano



reply via email to

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