| 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 :(.
| > 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.
Going into $build != $host is *not* good, you don't hold the control
because the control is no longer one of your acts, but a consequence
of several acts. Your control is going loose.
And btw, do you mean host_alias != build_alias, or really build !=
host? Because the latter can only work with AC_CANONICAL_HOST being
run. And it would be wrong.
| > From a physicist point of view, --host is necessarily *the* right
| > solution: it is extremely simple, and explains everything.
|
| But it is confusing.
I don't think so: a proper explanation in the --help of --host is just
what it takes.
| IMO, we should take smaller steps in the right direction. Since we're
| going to introduce an incompatible change, we should first warn about
| the change in behavior, give people time to get used to it, then make
| the final change. Meanwhile, we may have to support a messy set-up,
| but that's the right way to deal with users.
I don't buy that: nobody will never change anything in their scripts,
and we will keep that mess in Autoconf for ages. I don't believe
*one* second Autoconf 3.0 will ever exist. And I'm surprised to see
you do.
| Alexandre> If only one of --build, --host and TRIPLET is specified,
| Alexandre> use it for host and build, and assume not cross-compiling.
|
| If only --host was specified, warn the user that he probably meant
| --build, and proceed as above.
Sorry, but this is what I call confusing! And you are rejecting the
fact that you don't need to specify --build, you just need --host.
This is a huge step backwards!
| Alexandre> If at least two of --build, --host and TRIPLET are
| Alexandre> specified, assume cross compilation if they differ.
| Alexandre> TRIPLET would be used as the default for either --host or
| Alexandre> --build, whichever was not specified.
|
| Alexandre> TRIPLET, if specified, would also be used as the default
| Alexandre> for target, unless --target is specified. If all of
| Alexandre> --build, --host, --target and TRIPLET are specified, issue
| Alexandre> an error (warning?) message indicating that TRIPLET is
| Alexandre> useless.
|
| If TRIPLET is specified, emit a warning suggesting that the user
| should have used --build, --host and/or --target instead.
|
|
| > Really, I find this very messy. Messy to implement, to document, and
| > to understand. How can you reasonably understand what is going to
| > happen? When will you know that what-is-typed-is-what-you-meant?
|
| The rule is simple: --build specifies the build system and the default
| for --host.
OK.
| --host specifies the host system and the default for
| --target; if it differs from --build, assume a cross-compiler is in
| use; for backward compatibility,
| if --build is not specified, warn and
| default it to --host.
Not OK, this is wrong IMHO.
| --target specifies the target platform, when
| creating compilers/assemblers/linkers/debuggers/etc. TRIPLET produces
| a warning and overrides any other defaults, and is provided only for
| backward compatibility.
!!!
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?
| > This solution is about as atrocious as the old one was.
|
| Indeed. But, IMO, it's a step in the right direction, that won't hurt
| anyone like the installed change did. We really need a
| backward-compatible change, at least for some time, so that people
| (including Cygnus customers that have been trained by Cygnus people
| and/or documentation) can be made aware of the change, start doing the
| right thing, so that we can discontinue the old, wrong way of doing
| it.
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 would have appreciated that the Autoconf people were involved too.
|
| And they'd have appreciated that the Cygnus people were involved in
| the discussion when it started here :-)
I was under the impression we did :( What is the address?
