Re: Problem with AC_REQUIRE expansion order

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 8/5/2008 9:00 PM:
| |> +m4_ifval([$1], [m4_divert_text([INIT_PREPARE],
| |> +  [ac_prog_cc_list='$1'])])dnl
| | This won't like
| |   AC_PROG_CC(['cc -m32' "cc -m64"])
|
| Ouch.  And that looks like a real possibility of being in existing code.

Actually, I'm starting to doubt that.  The current code allows arguments,
but does not distinguish between the same basename with distinct
arguments.  The search stops as soon as a basename is found on the path,
then configure falls over and dies if the first located compiler fails to
compile.

In other words, with your example, if cc exists, it will only ever be
attempted as 'cc -m32'; the 'cc -m64' variant is never attempted (either
cc is on the path, so the search has stopped, or it is not, so repeating
the search will fail to find it once again).

That's not to say that this behavior is wrong.  Perhaps we should let
AC_PROG_CC use AC_PATH_PROGS_FEATURE_CHECK rather than AC_CHECK_TOOLS
under the hood, to allow the search to continue until all suggestions in
the list have been exhausted.  Or even introduce
AC_PATH_TOOLS_FEATURE_CHECK.  But this is starting to get much bigger than
my original patch.

So, how to proceed?  Where do we draw the line at an acceptable patch for
releasing 2.63?  Right now, I'm leaning towards doing just the simple:

ac_prog_cc_list="$1"

which will handle AC_PROG_CC([$list]) but not arguments.  But this would
be a regression if there are any AC_PROG_CC(['cc -arg']) in the wild.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiZJBkACgkQ84KuGfSFAYDFMwCeOczrkL3qtfkLhn6QlUoHee4b
JosAn3O6qMVVsHiOscJpS48bMENoChkh
=mKAK
-----END PGP SIGNATURE-----