From: Ian Lance Taylor <ian@airs.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Geoff Keating <geoffk@geoffk.org>,
Nathanael Nerode <neroden@twcny.rr.com>,
gdb-patches@sources.redhat.com, binutils@sources.redhat.com,
newlib@sources.redhat.com, gcc@gcc.gnu.org, autoconf@gnu.org
Subject: Re: AC_NO_EXECUTABLES is useless for GCC
Date: Tue, 10 Dec 2002 01:01:00 -0000 [thread overview]
Message-ID: <m3k7ii9z47.fsf@gossamer.airs.com> (raw)
In-Reply-To: <oradjexvxi.fsf_-_@free.redhat.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> writes:
> I think we'll be better served by declarative macros such as
> AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
> sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
> out if it fails, but rather it sets a variable indicating the result
> of the test, such that we could base our decision on whether to
> perform additional link tests on this variable. Does it sound like
> this would work?
This approach sounds weird to me. The basic problem is that
AC_PROG_CC does the wrong thing for libstdc++ and a few other
configure scripts--namely, it executes the test of whether the
compiler works. It seems to me that AC_PROG_CC should call some
helper macros--perhaps just two--and that libstdc++ should call a
subset of those helper macros--perhaps just one.
Adding macros which change the behaviour of other macros seems
confusing. I don't see the advantage of that at all.
Ian
next prev parent reply other threads:[~2002-12-10 6:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-05 14:40 [RFC] Update to current automake/autoconf/libtool versions Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg
2002-12-06 10:21 ` Tom Tromey
2002-12-07 13:06 ` Alexandre Oliva
2002-12-07 16:03 ` Zack Weinberg
2002-12-09 19:16 ` Alexandre Oliva
2002-12-09 21:52 ` Geoff Keating
2002-12-09 22:05 ` AC_NO_EXECUTABLES is useless for GCC Alexandre Oliva
2002-12-10 1:01 ` Ian Lance Taylor [this message]
2002-12-08 13:11 ` [RFC] Update to current automake/autoconf/libtool versions Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k7ii9z47.fsf@gossamer.airs.com \
--to=ian@airs.com \
--cc=aoliva@redhat.com \
--cc=autoconf@gnu.org \
--cc=binutils@sources.redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=geoffk@geoffk.org \
--cc=neroden@twcny.rr.com \
--cc=newlib@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox