bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Stefano Lattarini]

Hi Bob, thanks for the prompt feedback.

On 01/03/2013 08:14 PM, Bob Friesenhahn wrote:
> On Thu, 3 Jan 2013, Stefano Lattarini wrote:
>>
>> The known make implementations that does not support recursive variable
>> expansion -- as in $(foo_$(bar)) -- should by today be either very old
>> or very "fringe"; so it would be nice if, starting from Automake 1.14,
>> we could begin assuming unconditionally that this feature is supported.
> 
> This would be nice.
> 
>> Users of those old-and-poor make implementations can still download
>> and install GNU make (which, as we all know, doesn't require a
>> pre-existing make installation to be bootstrappped).
>>
>> This change would simplify our codebase a little, would reduce the
>> number of configure-time checks for the client packages (eventually,
>> at first we should still check for our intended feature, and bail
>> out loudly and with a clear error message if that is not working),
>> and also reduce the differences between mainline Automake an
>> Automake-NG.
> 
> How would you know the make program that the user will actually use?
>
Assume it is either the default one, or that $MAKE is passed to
configure.  Automake-generated configure code has been doing this
assumption since a long time, so nothing new here (albeit the
situation is clearly suboptimal).

> Some systems may have three or four 'make' type programs installed.
>
Ah, lovely Solaris :-)

>> So, here is the tentative roadmap:
>>
>> * Automake 1.13.2
>>
>>  - Add a 'spy-make-recurs-var.sh' test verifying that the make
>>    implementation used in the testsuite truly support recursive
>>    variable expansion..
> 
> I suspect that there is a configure check to find the most
> 'worthy' make program on the system (e.g. GNU make).
>
Nope, no such check from us.

* Not in configure.  Here is how Automake-generated configure code
  looks for the make program (slightly tweaked for readability):

    am_make=${MAKE-make}
    echo -n "checking whether $am_make supports nested variables... "
    if ${am_cv_make_support_nested_variables+:} false; then :
       echo -n "(cached) " >&6
    else
      ...

* Especially not in the testsuite.  In fact, to enhance coverage,
  we even go to some length to ensure non-GNU tools are preferred
  to the GNU ones!  There even is this comment in Automake's own
  'configure.ac', in the section looking for tools and programs
  to be used in the testsuite:

    # Prefer generic compilers to GNU ones when possible.  This will
    # ensure more testsuite coverage "in the wild".
    # Note that we don't look for the MSVC C/C++ compiler here.  This
    # is deliberate; for more discussion and rationale, see:
    # <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00130.html>

    AC_MSG_NOTICE([will now look for generic compilers])

> This search for, and use, of the most worthy make program may foil
> this approach to detect broken make programs.
>
No such problem, in light of the above.

> Also, many/most people who install Automake from sources likely
> don't execute the test suite, especially on older slow systems
>
That's why I proposed, in my second point (which you have elided,
apparently) a runtime probe to be added to *every* configure script
generated from a AM_INIT_AUTOMAKE-using configure.ac:

  - Enhance the checks in the AM_SILENT_RULES macro to print a loud
    message at configure runtime if the make implementation on the
    system isn't able to grasp recursive variable expansion, telling
    the user to report the situation to our upstream (bug-automake).
    This is of paramount importance for us to know how the situation
    "in the wild" really is.  In the past, Autoconf did something
    similar to ensure the presence of shell functions in all the
    shells worth supporting.

> If GNU make is installed on the system and called 'gmake' but
> the user types 'make' and 'make' does not support recursive
> variable expansion, what will happen?
>
Nothing, since configure does not look for gmake, but only for
${MAKE-make}.  If the user exports "MAKE=gmake" and then runs
"make", well, he's asking for troubles -- and he'll get them.

Hope that clarifies the matter a little.

Thanks,
  Stefano