>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Aug 7, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Are you saying you are looking for a 2.13 and 2.50 compatible
>> solution? Why?
Alexandre> Because we're not switching to CVS autoconf right now.
Can you see any other kind of additional pressure the GCC team could
put on us? I'm tired of all this.
I am very much in favor of helping the GCC team, just like any another
user of Autoconf, but really, Autoconf has enough with its own
problems so that people come with such requests.
>> Really, I dislike macros which change some state, and change the
>> semantics of other macros.
Alexandre> I don't have a problem with that, as long as it's clean
Alexandre> enough. AC_NO_EXECUTABLES seems clean enough to me.
I do :) That's a hack, and hacks are to be avoided. That's an
exception in a rule based tools, and exceptions and logic don't mix well.
>> For one, it makes --trace lie. We'd better find exactly what is
>> the grain you need, and provide the equivalent macros.
Alexandre> Problem is that there are several macros that
Alexandre> AC_REQUIRE([AC_PROG_CC]), and AC_PROG_CC does all the work,
Alexandre> part of which we don't want.
Autoconf macros, or foreign macros?
>> What do you dislike in my proposal?
Alexandre> It doesn't look simple enough to me. It looks too much
Alexandre> like ``internals of autoconf'' to me; we shouldn't have
Alexandre> code like that in GCC's aclocal.m4/configure.in.
Well, between something based on AC_LANG_DISPATCH and some hacking, I
don't have the same picture. But I agree AC_LANG_DISPATCH is 2.50.
>> It's basically the same, but more Autoconf like, and more scalable.
Alexandre> Not if you want to do it with multiple languages and one
Alexandre> extender doesn't know about the other. Think of doing
Alexandre> define([AC_TRY_LINK_ORIGINAL],defn([AC_TRY_LINK])) multiple
Alexandre> times.
OK, ifdef([AC_TRY_LINK_ORIGINAL], ....). But you know that.
