Salut Pavel ! :)
| > So, would there be a strong opposition to its complete removal?
|
| I cannot say about "strong" opposition, but at least configure should exit
| with an error. The error message should perhaps mention "--host". I can
| imagine scripts using bare HOST, so we should be careful to inform people.
Well, there's already strong opposition, so :)
| It happened to me several times that a malformed option was understood as
| HOST. It is shame that "./configure foo" succeeds if AC_CANONICAL_* is not
| used.
Agree. This is one of the things I dislike in this approach.
| By the way, configure --help prints now:
|
| Usage: ./configure [OPTION]... [VAR=VALUE]... [HOST]
| ...
| Host type:
| --host=HOST configure for HOST [guessed]
| --build=BUILD configure for building on BUILD [BUILD=HOST]
| --target=TARGET configure for TARGET [TARGET=HOST]
|
| in all three cases: no AC_CANONICAL_*, AC_CANONICAL_HOST and
| AC_CANONICAL_SYSTEM. This is quite inconsistent.
The proposal I just sent got rid of the [HOST] stuff. As far as the
| Host type:
| --host=HOST configure for HOST [guessed]
| --build=BUILD configure for building on BUILD [BUILD=HOST]
| --target=TARGET configure for TARGET [TARGET=HOST]
is involved, it would be quite easy to include it only if
AC_CANONICAL_SYSTEM was used, but because we still seem to provide a
public access to AC_CANONICAL_HOST, it can quickly become hard to
track.
This is why I would like to reiterate a proposal I made: get rid of
AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only
AC_CANONICAL_SYSTEM.
I don't think maintainers need to ask themselves the question of which
of these they should run, I don't think the slight speed improvement
should be considered. So my proposal is that all these former names
become just an AC_REQUIRE of AC_CANONICAL_SYSTEM, to be guaranteed to
remain compatible, and we just document the latter. And we move into
it the --help portion.
How does it sound?
Akim
