On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> And btw, do you mean host_alias != build_alias, or really build !=
> host?
_alias, i.e., what the user specifies in the command line. So he's in
full control.
> | 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,
If they won't change their scripts, then it's their fault. By warning
in advance, we're exempting ourselves from being blamed for the change.
> 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.
We don't really have to wait for 3.0, but we must keep the warning in
place for a one or two years before taking the final step.
> | 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!
It may be confusing for *you*, but I'm pretty sure it won't be
confusing for 99% of the autoconf users out there. People hardly
understand the difference between --build and --host, and this warning
will hopefully get them to read the manual, and then they'll learn
about the change in behavior and the real difference between these
flags.
> And you are rejecting the fact that you don't need to specify
> --build, you just need --host. This is a huge step backwards!
We may have an `I-know-what-I'm-doing' option, such as --Host, for
example.
> | if --build is not specified, warn and
> | default it to --host.
> Not OK, this is wrong IMHO.
This is the key to make the transition easier to everybody, and to
enlighten people about the difference between --host and --build.
> 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?
I'll answer again: because this wouldn't solve the problem at hand.
There are dozens of scripts and manuals and people out there that
expect --host to set the default for --build. These people should be
warned in advance that they should now be specifying --build to
accomplish that. This will give everybody time to modify their
scripts and manuals, and to start using the new behavior. In fact,
the change that has already been installed in autoconf is incompatible
with the GNU Coding Standards!
http://www.gnu.org/prep/standards_42.html#SEC42
> the solution you propose does not give guarantees we will be cleaned
> from this. It is not enough temporary.
We can make it as long as we want. But I think we must keep the
backward-compatible behavior for at least one or two years.
> | 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?
Unfortunately, it's an internal mailing list, whose address must not
be given to outsiders :-(
Some Cygnite (probably me) should have warned them about this debate
and got whoever was interested involved. I was expecting anybody
interested would have been subscribed to this mailing list, but that
was not the case :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
