-----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 [EMAIL PROTECTED] -----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-----
