[Top][All Lists]
[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