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 a warning.
> | This should be enabled by AC_CANONICAL_HOST.
> |
> | 3) configure is aware of BUILD, HOST and TARGET. This should be enabled by
> | AC_CANONICAL_SYSTEM.
>
> Well, I must confess my approach to this situation is much more
> related based on the beauty of the code and of the interface we
> provide, than with the intention of addressing such problems (since I
> never had to face them). If you consider this is a serious issue,
> that there are truly people who get trapped with this, then we could
> introduce a special case for 2.
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 don't know if this justifies additional coding. It's up to you.
> Well, what you propose computes HOSTS additionally, and using SYSTEM
> will be extremely fast, since it is just re-decoding $build. Really,
> I don't think the cost issue can really matter here. I wouldn't be
> surprised to learn that configure spends more time in option
> processing alone.
I'm not concerned about speed. I'm concerned about confused people.
> Why? People which reached such a competence level that they
> cross-compile would really use --target to something for which it
> makes no sense?
Again, see the beginning of the thread.
Pavel
