public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Nathanael Nerode <neroden@twcny.rr.com>
Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: Partial autoconf transition thoughts
Date: Tue, 10 Jun 2003 00:59:00 -0000	[thread overview]
Message-ID: <orllwaagtj.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <20030610004025.GA26915@doctormoo>

On Jun  9, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> Alexandre Oliva said:
>> On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
>> 
>>> 4.  Specify the same thing for both
>>> 2.13: Both will be overridden; test $CC for cross mode.
>>> 2.57: Both will be overridden, will build natively.
>> 
>> Except that building natively is deprecated, and autoconf people have
>> already pushed for removing this alternative.  We probably don't want
> Whaaaat?  This seems like a rather dumb idea with no serious benefit.

Be my guest in pushing against this.  I tried it, and gave up.  The
idea that won was that, if you specify --host, you mean to cross
compile, even if you specify the same triplet that you specify for
--build.  I can't really say it's a bad idea, it just looks bad
because it's different from what we've had for a long time.  The
current test for $build = $host is there to ease the transition, and
it will go away in autoconf 3.0, whenever that comes out, hopefully
5-10 years from now.

> Let's look at this another way.  What are the *differences* between a
> build=host compilation and a build!=host compilation?

You can't run tests in the latter case, you can't assume that the
presence of file or device names in the build machiine reflects what's
going to be in the host machine.  I'm probably forgetting other
issues.

> I proceed on the principle that there are no real, fundamental 
> differences between a native configuration and a cross configuration, 
> and this generally creates the cleanest configury code.

I.e., assume you're always cross compiling?  That would be a
reasonable approach too, but there are some tests that you can't
possibly do in the cross case, autoconf lets you actually do them in
the native case as long as you set a safe default or alternate test
for the cross case.

> Absolutely.  We're already passing a complete set down to the 'target' 
> directories and to the 'build' directories.  I think we should also pass 
> a complete set down to the 'host' directories, and they should be bright 
> enough to understand that if build=host, build=host.  (Regardless of 
> what some autoconf people may be advocating.)

autoconf is not going to support this, so we have two options: stop
using autoconf, or following their lead.  I'm for the latter.  As much
as I've disliked the transition path, I do think their goal was a
perfectly reasonable one, and wish it had been like that from the
beginning.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

  reply	other threads:[~2003-06-10  0:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-10  0:40 Nathanael Nerode
2003-06-10  0:59 ` Alexandre Oliva [this message]
2003-06-10 10:59   ` Maciej W. Rozycki
2003-06-10 11:38     ` Andreas Schwab
2003-06-10 12:45       ` Maciej W. Rozycki
2003-06-10 22:06     ` Alexandre Oliva
2003-06-11 11:32       ` Maciej W. Rozycki
2003-06-11 18:04         ` Alexandre Oliva
2003-06-11 19:39           ` Maciej W. Rozycki
2003-06-11 20:39             ` Alexandre Oliva
2003-06-12 11:21               ` Maciej W. Rozycki
2003-06-12 12:10                 ` Bernd Jendrissek
2003-06-12 12:26                   ` Maciej W. Rozycki
2003-06-12 21:42                     ` Alexandre Oliva
2003-06-13 10:35                       ` Maciej W. Rozycki
2003-06-13 14:02                         ` Alexandre Oliva
2003-06-13 18:32                           ` Maciej W. Rozycki
2003-06-13 19:25                             ` Alexandre Oliva
2003-06-13 20:15                               ` Maciej W. Rozycki
2003-06-13 20:54                                 ` Alexandre Oliva
2003-06-14 14:33                                   ` Maciej W. Rozycki
2003-06-14 15:43                                     ` Alexandre Oliva
2003-06-14 18:27                                       ` Maciej W. Rozycki
2003-06-26  7:24                                         ` Alexandre Oliva
2003-06-28  0:35                                           ` Maciej W. Rozycki
  -- strict thread matches above, loose matches on Subject: below --
2003-06-10  1:40 Nathanael Nerode
2003-06-10  1:46 ` DJ Delorie
2003-06-09 22:02 Daniel Jacobowitz
2003-06-09 22:17 ` Andrew Cagney
2003-06-09 22:34 ` Alexandre Oliva
2003-06-09 23:14   ` Daniel Jacobowitz
2003-06-10  0:44     ` Alexandre Oliva

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=orllwaagtj.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=neroden@twcny.rr.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).