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!