autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with AC_REQUIRE expansion order


From: Ralf Wildenhues
Subject: Re: Problem with AC_REQUIRE expansion order
Date: Wed, 6 Aug 2008 23:06:17 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* Eric Blake wrote on Wed, Aug 06, 2008 at 06:10:02AM CEST:
> 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.

Sorry, then that was a bad example on my part.  The second could just as
well be "gcc -m64".  My point was that arguments can exist, and that
both single- and double-quoting can happen.

> 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.

Let's not go that much bigger way.  My remark was not a bug report.
We don't have to get things working that don't work ATM, we should
concentrate on fixing regressions without introducing new ones.

Is the bug originally reported even a regression?

> 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.

I don't know how to measure or decide that.  I believe I've seen such
usage before but I really can't say for sure, or point to an actual
example.  Sorry.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]