[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: document a surprising behaviour of macros AC_PROG_{CC,CXX,F77}
From: |
Stefano Lattarini |
Subject: |
Re: document a surprising behaviour of macros AC_PROG_{CC,CXX,F77} |
Date: |
Sun, 28 Feb 2010 16:16:05 +0100 |
User-agent: |
KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.2; i686; ; ) |
At Sunday 28 February 2010, Ralf Wildenhues <address@hidden>
wrote:
> Hi Stefano,
>
> thanks for the patch, and sorry for the delay on this.
>
> * Stefano Lattarini wrote on Sun, Feb 28, 2010 at 03:25:09PM CET:
> > This topic came up a while ago on bug-autoconf, but the patch I
> > posted there went unnoticed or was ignored.
>
> Well, I put it off for later because the right thing to do here
> would be to also add a set of AC_PROG_{CC,...}_WORKS macros that
> people can then use.
That sounds like a good idea.
> Also, a statement like this:
>
> > This behaviour may seem
> > surprising, but probably it cannot be fixed without breaking
> > backward compatibility in some way.
>
> states "we've given up on this", whereas the reason I've put it off
> was "I haven't done enough research to know for sure whether we
> can safely change semantics".
Oh. My misunderstanding. What about this statement instead?
"This behaviour may seem surprising, but is presently kept for
backward-compatibility reasons. This might change in a future
version, though, so try not to rely too much on it."
> The use of AC_REQUIRE tends to require us to provide macros which
> do not take arguments in the vast number of default uses, so that
> we can easily let them be required. Adding options IF-FAILS
> arguments to the AC_PROG_{CC,...} macros is bad because some of
> them already have optional arguments, some used to have them, and
> they are often AC_REQUIREd without options.
>
> IOW, I'd prefer to not promise anything now which we may be able to
> fix in a better way later.
Good points. My patch feels much less compelling now.
Regards,
Stefano