>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:

>> Well, I was definitely referring to the Cygnus' case, because
>> that's probably the largest trees we will ever find, so that's
>> probably where it is more likely to have momentum (definitely not a
>> critic, just a statement).  

(which was based on the size of the trees).

>> In the other cases, I think it is not unreasonable to have people
>> autoreconf.

Alexandre> It is totally unreasonable.  GCC and binutils are
Alexandre> bootstrapping tools (i.e., you may have to build them
Alexandre> before you can build anything else).  You can't require
Alexandre> people to run autoreconf before they're able to even
Alexandre> configure them.

OK, I see.  I was still under the impression that Cygnus was wrapping
the trees, I had not understood users were likely to assemble trees.


>> I had not understand the user herself was able to build the tree, I
>> thought you shipped trees.

Alexandre> Both GNU and Cygnus have always shipped source code.

Yes, of course.  That's not what I meant.



Alexandre> Do you think the solution is any worse than what we had?  I
Alexandre> agree it is worse than what we have now, in the CVS tree,
Alexandre> but what we have now is totally unacceptable from an
Alexandre> evolutionary point of view.  It breaks
Alexandre> backward-compatibility so badly that it goes against the
Alexandre> agreement we had, that the next release of autoconf would
Alexandre> be compatible with the previous one.

OK, I'm ``convinced'' :)

Alexandre> Yeeeeahh

Hey, wait that I send the message before answering!  :)

Do you think there is really a chance that in a not so distant future,
in this galaxy, we will reimplement the behavior we have in CVS?  I
fear we will never be able to, for instance because of the build
defaulting to host.



Alexandre> we haven't agreed upon yet, at least WRT --host implying
Alexandre> cross).

:)



>> But OK, the user is not supposed to use this.  The result is the
>> same anyway: for instance we keep the confusion between host and
>> build.

Alexandre> Nope: it will enlighten people about the difference.  

We should probably start explaining the future in INSTALL, no?



>> I'm terrified to see that build is sometimes the default for host,
>> and at other moments, it's the converse!

Alexandre> Look at it from the perspective of the old behavior.
Alexandre> Analize each set of arguments to configure, and think
Alexandre> whether the behavior is surprising or might confuse new
Alexandre> users in any of the cases.  If you find *any* such case,
Alexandre> please show me.

Yep, my statement was based only what we have, not what we had.



Alexandre> That's why we need a transition solution, with warnings
Alexandre> getting printed: to give people time to get used to the new
Alexandre> behavior, to let them see that it is better, to adjust
Alexandre> their scripts and documentation.  

Yes, that would be great, but it is not exactly what happens.  Your
proposal is moving Autoconf in between CVS and 2.13.  Closer to CVS,
agreed, but there are things which will no longer work the same way
after your patch is applied.  So it means afterwards, we will want to
make another incompatible step, which makes me feel uncomfortable.

But I approve your patch.



Alexandre> The only possible way is a long term transition, with a
Alexandre> backward- and forward-compatible solution.

And maybe documenting ./configure host_alias=sun4 cross_compiling=no.
Or make official a variable such as ./configure HOST=sun4, dunno.



>> All I'm asking is a means to preserve the new semantics and the new
>> interface.

Alexandre> My proposal doesn't break it.  Well, ok, it breaks the
Alexandre> `--host implies cross' principle, that I don't support when
Alexandre> host=build, anyway.

If you forget about TRIPLET, which is deprecated in any case,
something which is broken is the default for build.  But we can't
change this since that's precisely what would most differentiate 2.13
from 2.50, so we have to :(



Alexandre> - build is the platform on which you're building the
Alexandre> software

Alexandre> - host is the platform on which the software will run

Alexandre> - target is the platform for which the program being built
Alexandre> (typicall a cross assembler, compiler or debugger) should
Alexandre> generate code

Fine.



Alexandre> They all default to the result of `config.guess', unless
Alexandre> you specify either --build or --host.  In this case, the
Alexandre> default becomes the platform you specified.  If you specify
Alexandre> both, and they're different, `configure' will assume cross
Alexandre> compilation is taking place, so it won't run any tests that
Alexandre> require execution.  Target is assumed to be the same as
Alexandre> host, unless --target is explicitly specified.

Alexandre> Hint: if you mean to override the result of `config.guess',
Alexandre> prefer --build over --host.  In the future, --host will not
Alexandre> override the name of the build platform.  Also, when you
Alexandre> only specify --host, `configure' will assume
Alexandre> cross-compilation if your compiler doesn't seem to be
Alexandre> working properly, instead of giving you an error.

OK too.  I don't know if you intentionally dropped TRIPLET from the
documentation, but I'm all for it.

        Akim

Reply via email to