GNU bug report logs - #13349
Could we just assume support for make recursive variable expansion unconditionally?

Previous Next

Full log

Message #64 received at 13349 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Subject: Re: bug#13349: Re-execute with the "correct" make implementation
Date: Fri, 04 Jan 2013 01:17:26 +0100

[Dropping Automake-NG]

On 01/04/2013 01:12 AM, Eric Blake wrote:
> On 01/03/2013 04:54 PM, Stefano Lattarini wrote:
>>> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
>>> provides @SET_MAKE@ for substitution in Makefiles;
>>>
>> Right, I had forgotten about that.  I somehow just took it for granted
>> that it was all Automake's doing ...
>>
>> So, it would again be Autoconf that should implement the probe we had
>> talked about, if we decide to go down that road ...
> 
> Well, when it comes to letting MAKE be precious, AC_PROG_MAKE_SET (and
> thus autoconf) is the logical solution.  However, as for actually
> _using_ @SET_MAKE@, that is automake's lib/am/header-vars.am, so I'm
> still inclined to think that a sanity probe belongs best in Automake
> (that is, autoconf provides the tools for finding out what the user
> wants to use as $(MAKE), but automake then takes those tools to turn it
> into a proper Makefile.in with the smartest possible semantics).  In
> fact, we may decide that automake wants to invoke AC_PROG_MAKE_SET, but
> _not_ use @SET_MAKE@, by instead using its own more complete sanity
> checking code.
>
Indeed, this is all very sensible.  Yet I expounded an opposite opinion
just few minutes ago.  Clear indicator it's time to go to bed :-)

Regards,
  Stefano

Previous Next

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