| > bug in `configure.in'. Must we be bugward compatible?
| bugward :)
|
| I think so, cf. below.
I think below you do demonstrate that a buggy configure.in will see
the bug revealed by this patch. I agree on this. My question is
more:
Is being bugward compatible more important than having a clean
and unambiguous semantics?
| > If so, we can
| > set host to host_alias at the end of the handling of the options,
| No, host and host_alias can differ, and configure script could
| exploit this for whatever reason.
That's right, they are different, and I am not trying to erase the
differences, on contrary: I want to keep them separate. Let me
rephrase my patch:
In Autoconf 2.13 `$host' before AC_CANONICAL is what the user
gave for --host, that is `$host_alias' after AC_CANONICAL, and
`$host' becomes the normalized stuff after AC_CANON.
My proposal says that `$host_alias' is what the user gave to
--host, before and after AC_CANON, and `$host' is the
*canonicalization* of `$host_alias' *after* AC_CANON was run,
as the name says.
As for the ``configure script could exploit this for whatever
reason.'', I absolutely agree, but my claim is when `$host_alias' is
wanted (i.e., *not* $host), then we really want what the *user* said,
i.e., IMHO, it is right that host_alias='' when the user didn't
--host. Otherwise you meant something else.
| Eg. have a look at the output of the configure script below
| (autoconf 2.13):
|
| # cat configure.in
| AC_INIT(Makefile.am)
| echo "host:$host"
| echo "build:$build"
| echo "target:$target"
| AC_CANONICAL_SYSTEM
| AM_INIT_AUTOMAKE(test,0)
| echo "host:$host host_alias:$host_alias"
| echo "build:$build build_alias:$build_alias"
| echo "target:$target target_alias:$target_alias"
| AC_OUTPUT(Makefile)
|
| # ./configure --host=sh-rtems --build=i386-linux --quiet
| creating cache ./config.cache
| host:sh-rtems
| build:i386-linux
| target:NONE
| host:sh-unknown-rtems host_alias:sh-rtems
| build:i386-pc-linux build_alias:i386-linux
| target:sh-unknown-rtems target_alias:sh-rtems
| updating cache ./config.cache
| [..]
|
| As you can see it makes an essential difference if using
| $[host|build|target] or $*_alias :)
Your example emphasizes my point:
| host:sh-rtems
| ...
| host:sh-unknown-rtems
My claim is that this is not normal.
| Another difference has been that host, build and target were present
| all autoconf configure scripts by default, even if AC_CANONICAL_*
| etc. had not been used in a configure.in. Therefore I assume, there
| might exist configure scripts which rely on the values of host,
| build, target without using AC_CANONICAL_*, esp. in packages not
| using automake/config.guess/config.sub.
I can't find an example of this. I've looked in several packages
though. But really, it doesn't make sense to me to use $host
etc. with AC_CANON.
The only use I know for these guys is $target_alias- when you install
cross-compilers, and $host_alias- when you look for a cross-compiler.
1. these are under the responsibility of Autoconf, and 2. anyway since
they were correctly used in Autoconf, the code doesn't even need to be
changed. The only difference is *positive*: these two changes are
generalized to *all* the packages, not only those running AC_CANON.
Hm, I find it hard to explain what I feel :) Feel free to spot and
denunciate my dark side :)
Akim
PS/ Ah ah! I think I just understood your answer wrt:
| > If so, we can
| > set host to host_alias at the end of the handling of the options,
| No, host and host_alias can differ, and configure script could
| exploit this for whatever reason.
My proposal is to do that just at the end of the options handling, so
it would behave exactly the same way for $host as before (its values
can suddenly change), but at least `host_alias' is *always* set, and
correct.
This proposal is only to help the Autoconf body swallow this big pil,
but I am against it. Thou shalst nost use whast thou hast nost
defined. (Hm, or something like this :).
If you want what the user said, then you want *empty* when the user
said nothing. If you want a string characterizing the platform, you
want config.(guess|sub) to be run.
