Ian Lance Taylor wrote:
>
>Date: Fri, 21 Apr 2000 19:03:50 -0400 (EDT)
>From: Pavel Roskin <[EMAIL PROTECTED]>
>
> [..]
>I'm not sure whether AC_CANONICAL_TARGET should be dropped. An important
>word here is "canonical". Autoconf used to provide some service to the
>package,
Date: Fri, 21 Apr 2000 19:03:50 -0400 (EDT)
From: Pavel Roskin <[EMAIL PROTECTED]>
In fact GNU software has already outgrown the concept of a single TARGET.
GDB and Binutils support multiple targets. Even gcc supports many targets,
i.e. gcc and "gcc -mlittle-endian" on PowerPC gene
Hello, Peter!
> I don't think this buys anything. First let me say that this "target"
> thing is about the most confusing thing about Autoconf documentation and
> concept-wise, especially when thrown together with build and host. The
> latter two configure the build process to some extend or othe
On Fri, 21 Apr 2000, Earnie Boyd wrote:
> --- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> -8<-
> > Well, this thread began with a message from Mo DeJong <[EMAIL PROTECTED]>
> > (Cygnus dot Com !!!) who tried to use --target where is should have been
> > --host.
> >
>
> I wouldn't give too much cr
I like this idea. I just started trying to use autoconf to do cross
compiles yesterday and I can tell you that it is VERY hard to figure
out which of the AC_CANONICAL_{BUILD, TARGET, HOST, SYSTEM} macros one
should be using. The docs did not help much, there was a cryptic
note about only needing H
Akim Demaille writes:
> This is why I would like to reiterate a proposal I made: get rid of
> AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only
> AC_CANONICAL_SYSTEM.
I don't think this buys anything. First let me say that this "target"
thing is about the most confusing thing about Autoconf d
Johan Danielsson writes:
> This of course depends on what the CC_STDC macro means,
It effectively tries to give a couple of flags to the compiler to make it
a little more modern. That means accepting prototypes and perhaps const,
etc.
> but if it tests for a `ANSI C' compiler, -std is not enoug
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
-8<-
> Well, this thread began with a message from Mo DeJong <[EMAIL PROTECTED]>
> (Cygnus dot Com !!!) who tried to use --target where is should have been
> --host.
>
I wouldn't give too much credance to (Cygnus dot Com), newbies do exist there
too, n
Akim Demaille wrote:
>
> | Salut, Akim :-)
>
> Moin moin!
>
> (Well, I don't know what this means, but it sounds very friendly :)
> There's a guy on some mailing list who starts each of his messages
> with `moin moin').
>
It's a common greeting phrase used in North German dialects, literally
"
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Ian> HOST_CC is a name used in the gcc Makefile. It is the same thing
Ian> as CC_FOR_BUILD. The gcc Makefile used the name HOST_CC long
Ian> before we sorted out the meanings of build, host, and target.
Good to know, thanks!
Ian> The
From: Akim Demaille <[EMAIL PROTECTED]>
Date: 21 Apr 2000 18:37:17 +0200
Could you detail why you prefer CC_FOR_BUILD over BUILD_CC?
I simply think it makes the use of the environment variable clear. We
have many Makefiles already which use CC_FOR_BUILD, CC_FOR_HOST, and
CC_FOR_TARGET.
Moin moin :-)
> Cause warnings!?! Hm. Sounds a bit hard, but doable. But I'm not
> sure to understand what would make it so interesting?
Well, I don't insist.
> | 2) configure is aware of BUILD and HOST. config.{guess,sub} are
> | ditributed. --build and --host are accepted, --target causes
Date: Fri, 21 Apr 2000 10:07:32 -0400 (EDT)
From: Pavel Roskin <[EMAIL PROTECTED]>
Since the forthcoming Autoconf 2.15 (or should it be 2.50?) will be very
different from 2.13 the idea of using BUILD_CC seems to be justified.
If you make this change, please use CC_FOR_BUILD instead o
I haven't closely read everything in this thread. I just want to note
a historical point.
A long time ago, we decided that if --host were specified, $build
would default to $host.
This is because before config.guess was invented, people were used to
typing `configure HOST' as in `configure sun4
Date: Fri, 21 Apr 2000 06:55:34 -0700 (PDT)
From: Tom Tromey <[EMAIL PROTECTED]>
Mo> Ok, I can buy that --host argument, but then why does using --host
Mo> also not work?
I don't remember the details or the history here. (I'm sure Ian does,
but I don't know if he lurks here or
From: Akim Demaille <[EMAIL PROTECTED]>
Date: 21 Apr 2000 15:33:24 +0200
Nevertheless, what I don't really understand is the default to
"$HOST_CC". Why should BUILD_CC default to HOST_CC? How could using
a HOST_CC, which I understand as a compiler for the HOST we target,
helps
| Salut, Akim :-)
Moin moin!
(Well, I don't know what this means, but it sounds very friendly :)
There's a guy on some mailing list who starts each of his messages
with `moin moin').
| > This is why I would like to reiterate a proposal I made: get rid of
| > AC_CANONICAL_{BUILD, TARGET, HOST}
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I used --target as the "driving force". I recall looking at
Harlan> --build, and for whatever reason found that I needed to use
Harlan> --target in order to detect the cross-compile. I probably
Harlan> wrote a small configure.in
Salut, Akim :-)
> This is why I would like to reiterate a proposal I made: get rid of
> AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only
> AC_CANONICAL_SYSTEM.
I still want to have choice between three situations:
1) configure is not aware of BUILD and HOST. config.{guess,sub} are not
ditri
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> This is one of the things I dislike in this approach.
In addition that I think it is wrong that TIMTOWTDI :)
Akim> How does it sound?
Well, how does it look? Autoconf's own configure now says:
---
The NTP project uses a/a for cross-compiles for the VxWorks port (at least;
I think there is another target that gets built but offhand I forget what it
is).
For whatever reason, when I implemented this (a couple of years ago, as I
recall), I used --target as the "driving force". I recall lookin
Salut Pavel ! :)
| > So, would there be a strong opposition to its complete removal?
|
| I cannot say about "strong" opposition, but at least configure should exit
| with an error. The error message should perhaps mention "--host". I can
| imagine scripts using bare HOST, so we should be carefu
Hello, Akim!
> Pavel> Usage of HOST without --host= is error-prone and should be
> Pavel> connsidered as deprecated (IMHO).
>
> So, would there be a strong opposition to its complete removal?
I cannot say about "strong" opposition, but at least configure should exit
with an error. The error mes
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 21, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Usage of HOST without --host= is error-prone and should be
Pavel> connsidered as deprecated (IMH
On Apr 21, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Usage of HOST without --host= is error-prone and should be
Pavel> connsidered as deprecated (IMHO).
> So, would there be a strong opposition to its complete removal?
Certa
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Usage of HOST without --host= is error-prone and should be
Pavel> connsidered as deprecated (IMHO).
So, would there be a strong opposition to its complete removal?
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello!
>> Nevertheless, what I don't really understand is the default to
>> "$HOST_CC". Why should BUILD_CC default to HOST_CC? How could
>> using a HOST_CC, which I understand as a compiler for the HOST we
>> target, helps unders
Hello!
> My question is should specifying the HOST as a single argument as
> opposed to --host=HOST be any different? Shouldn't it be the same?
> Actually, is there any point in keeping two different interfaces to
> the same feature?
I believe using HOST as a single argument comes from the old
Hello!
> Nevertheless, what I don't really understand is the default to
> "$HOST_CC". Why should BUILD_CC default to HOST_CC? How could using
> a HOST_CC, which I understand as a compiler for the HOST we target,
> helps understanding the nature of the build system.
Because I assumed it's a lon
Mo> Ok, I can buy that --host argument, but then why does using --host
Mo> also not work?
I don't remember the details or the history here. (I'm sure Ian does,
but I don't know if he lurks here or not.)
Practically speaking, nearly everybody who does regular cross-compiles
does so on in the con
| Akim Demaille wrote:
| >
| > To make my question about $nonopt clearer, I'd like to know if there
| > is any reason to distinguish HOST when it comes from --host=HOST, and
| > HOST went it comes from ./configure HOST.
s/went/when/
| Canadian Crosses:
|
| Until now you had to use eg. this:
|
There is something I don't understand very well. What is it that
config.guess is actually guessing? Given that it is heavily uname
based, it seems to be pretty much a build-config.guess.
But given that it does use CC, which might be cross, it seems to also
have a host-config.guess flavor, right
On Apr 21, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> To make my question about $nonopt clearer, I'd like to know if there
> is any reason to distinguish HOST when it comes from --host=HOST, and
> HOST went it comes from ./configure HOST.
I think these should be equivalent.
--
Alexandre
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 21, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Arg. I'm even more lost :) Up to now the logic was that the host
>> was the default for target and build, now you seem to mean that the
>> build should be the
Akim Demaille wrote:
>
> To make my question about $nonopt clearer, I'd like to know if there
> is any reason to distinguish HOST when it comes from --host=HOST, and
> HOST went it comes from ./configure HOST.
>
Canadian Crosses:
Until now you had to use eg. this:
configure --build=`//config.gu
On Apr 21, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Arg. I'm even more lost :) Up to now the logic was that the host was
> the default for target and build, now you seem to mean that the build
> should be the default for the host?
I think that's the only sane approach, because the buil
To make my question about $nonopt clearer, I'd like to know if there
is any reason to distinguish HOST when it comes from --host=HOST, and
HOST went it comes from ./configure HOST.
I see none, but...
Akim
| On 21 Apr 2000, Akim Demaille wrote:
| > > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
| >
| > Alexandre> Sounds good to me (i.e., you've got one approval; a patch
| > Alexandre> needs two to be installed in the autoconf CVS tree).
| >
| > I confess I'm a bit lost by the ch
On 21 Apr 2000, Akim Demaille wrote:
> > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> Sounds good to me (i.e., you've got one approval; a patch
> Alexandre> needs two to be installed in the autoconf CVS tree).
>
> I confess I'm a bit lost by the change. We're m
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Sounds good to me (i.e., you've got one approval; a patch
Alexandre> needs two to be installed in the autoconf CVS tree).
I confess I'm a bit lost by the change. We're moving from
ac_cv_host_alias=`$ac_config_guess`
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > On 21 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >>
> >> > So if it should have been "internal" then why do I need to add the
> >> > AC_CANONIC
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 21 Apr 2000, Alexandre Oliva wrote:
>> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>>
>> > So if it should have been "internal" then why do I need to add the
>> > AC_CANONICAL_BUILD macro to my configure.in file to get cross
>>
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > So if it should have been "internal" then why do I need to add the
> > AC_CANONICAL_BUILD macro to my configure.in file to get cross
> > compiling to work?
But the docs tell me I only need AC_CA
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> So if it should have been "internal" then why do I need to add the
> AC_CANONICAL_BUILD macro to my configure.in file to get cross
> compiling to work?
You'd use AC_CANONICAL_SYSTEM.
> In looking at the source, I also came across this AC_C
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > The documentation seems to indicate that the only macro I
> > would need was AC_CANONICAL_HOST? Are the docs wrong about that?
>
> You'd seldom need information about the build platform, and you
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> * acgeneral.m4 (AC_CANONICAL_THING):
> Fixed macro so that config.guess is run for both
> AC_CANONICAL_HOST and AC_CANONICAL_BUILD. This
> fixes detection of the diff in host vs build
> so that cross c
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> The documentation seems to indicate that the only macro I
> would need was AC_CANONICAL_HOST? Are the docs wrong about that?
You'd seldom need information about the build platform, and you'd only
need information about the target platform w
I think I have found the cause of the bug in autoconf. The problem
was that the build system was not getting detected properly.
Here is an example configure.in that showed the problem.
mo(~/foo)% cat configure.in
AC_INIT(foo.cpp)
AC_PREREQ(2.14)
AC_CANONICAL_HOST
AC_CANONICAL_BUILD
AC_LANG_CPLU
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > There are a couple of problems with this approach. It compares the
> > result of running config.guess to what the user passed in with
> > --host, but I am not sure we actually want the configure
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> There are a couple of problems with this approach. It compares the
> result of running config.guess to what the user passed in with
> --host, but I am not sure we actually want the configure script to
> continue to think it is running on a i
Ok, lets get that implemented now.
Here is "kind of" what I want to do.
AC_INIT(foo.cpp)
AC_PREREQ(2.14)
cross_host=$host
host=NONE
AC_CANONICAL_HOST
AC_LANG_CPLUSPLUS
if test "$cross_host" != "NONE" && test "$cross_host" != "$host"; then
AC_CHECK_PROGS
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 20, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > But when I try to run ./configure with a target argument, it does not
> > use the right compiler.
>
> --target is used only for compilers, linkers, etc, to specify the
> platform *for which* the
On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Ok, I can buy that --host argument, but then why does using
> --host also not work?
Because that was never implemented?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companya
On Apr 20, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> But when I try to run ./configure with a target argument, it does not
> use the right compiler.
--target is used only for compilers, linkers, etc, to specify the
platform *for which* the programs should generate code. I think what
you want
54 matches
Mail list logo
