>>>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> 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.
Peter> I don't think this buys anything.
Well, it simplifies both the code and interface. But at that time I
was convinced it was better for the users and the maintainers, now
Pavel convinced me that it's better for the users that the maintainers
can specify what level is supported.
Peter> Target is really just another option to configure the runtime
Peter> behaviour of the package to be built. As such it should
Peter> probably be more something like --enable-target, but I won't
Peter> get into that now.
Very nice point!
Peter> If you want to make a change I'd claim that it would be much
Peter> more logical to get rid of AC_CANONICAL_SYSTEM instead and let
Peter> people explicitly call CANONICAL_{HOST|BUILD} if they want
Peter> information about the host or build system, whyever they would
Peter> need that. It's just as bogus to list --build as an option if
Peter> you don't actually evaluate it (or don't even care, as is
Peter> probably the case most of the time).
OK. Actually one of the reason why I was against keeping AC_CAN_HOST
and AC_CAN_SYS was that it is asymmetrical. But if we keep
AC_CAN_(HOST, BUILD, TARGET), I'm fine.
Peter> I don't really believe that recognizing that AC_CANONICAL_xyz
Peter> was called and adjusting the help output accordingly should
Peter> prove exceedingly difficult.
Adjusting the help output is not what frightens me most, although IMHO
it does mean another diversion, which is always a bit painful.
Rejecting --target when it is not supported is a bit more painful
IMHO.
I see two means to handle this:
1. we add diversions which makes it possible to specify some
processing of the options, and we don't support --target etc. by
default.
2. when AC_CAN_TARGET is called, a variable is set very high in
configure which tells the options handling machinery that --target
is enabled.
1. is simpler and more powerful, OTOH, it might give a means to people
to include new non standard options, which we want to avoid. But it
would have helped us to catch --suffix-program, --x-includes
etc. which are not used.
2. is simple too, and will give better error diagnostics: this
configure doesn't support --target, instead of unknown option.
I'll go for 2, but I can be convinced 1. is better.
Peter> I can take a stab at it if you don't want to.
I'll do it :) It's the kinda stuff I like to play with in Autoconf :)
Akim
