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

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.

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

1. Certain tools used while building have different names.
I have effectively isolated this issue into macros in config/acx.m4.
They can be improved if necessary, but they're already quite clever.
More importantly, *we* have control over these and can make them decide
based on *our* choice of when it's appropriate.

2. Testing can be done on the build machine.
Not a configuration issue!

3. Certain headers are to be found in a different place.
This is a legitimate difference, which might induce a desire for 
'cross-building' when build=host, but it can be specified explicitly in 
other ways already, I believe.

4. Certain libraries are found in different places.  In the case of 
static linking, this is the same as the above.  In the case of dynamic 
linking, this should be manually overridable (and it seems to be 
moderately hit-and-miss in the cross case anyway, given 
inconsistent dynamic library naming and locating schemes).  

I can think of no other differences.

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.


>What configure arguments?  Did you pass i386-linux in the command
>line?  Maybe one of --build or --host?  The worst case to handle IMO
>is that of passing --build, since then autoconf 2.13 directories will
>guess --host from config.guess, whereas autoconf 2.57 will default
>host to build.  If they're different, we get an inconsistent build
>across directories.  That's why I think we should resolve the flags in
>the top level, and decide what to pass to each sub-directory.

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.)

--Nathanael

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

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-10  0:40 Nathanael Nerode [this message]
2003-06-10  0:59 ` Alexandre Oliva
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=20030610004025.GA26915@doctormoo \
    --to=neroden@twcny.rr.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).