On 26 Jun 2000, Akim Demaille wrote:
>
> | On Jun 19, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | > I'm sorry, but I disagree. The only sane and simple definition of
> | > cross-compilation is when --host is specified.
> |
> | It might be simple, but I'm not sure it's sane. If host and build are
> | identical, it doesn't make sense to assume we're cross-compiling.
>
> I'm really annoyed by this, but it seems I'm the only one to be
> bugged. So I OK the patch :(.
Are you talking about the patch I sent in to avoid a cross compile
if the same --build and --host are given?
> | > For instance you might be willing to use --host = --build just to
> | > check how your configure behaves in a (comfortable)
> | > cross-compilation situation.
> |
> | I don't buy that. I could just specify any other arbitrary --host to
> | check how configure would behave, or specify a minimally different
> | --build system.
>
> So you have to know what system is close to the system you run, and
> you need to have a system that has such a sibling. I don't like host
> = build because the whole problem with the previous version of
> Autoconf was that you had no control over cross_compiling. Now you
> have a perfectly clear control over it: --host.
In this case, I don't think anyone would really expect
--build=FOO --host=FOO to do a cross compile.
...
> I'm asking the question again: can't we enable that stuff only when
> given a special option such as --with-old-machine-options-semantics or
> whatever? Your proposal is a step backwards into the dark side of
> cross compilation (I understand the pressure you face), but the
> solution you propose does not give guarantees we will be cleaned from
> this. It is not enough temporary.
>
> Or an ennvar?
>
> I also proposed that cross_compiling would be imported from the env,
> isn't this enough for people to make the transition?
>
> And what about the wrapper proposal?
>
> I understand this. But really, can't we have a wrapper for them? We
> are destroying the simplicity, the evidence of the current
> implementation, which results in, again, obscure things. For
> instance, build should *not* default to host.
I thought there was already a switch for cygnus behavior.
--cygnus assume program is part of Cygnus-style tree
Would it be possible to put this old style --host is really
--build stuff into the set of options activated when --cygnus
is passed in?
Mo DeJong
Red Hat Inc
