| Akim Demaille wrote:
| >
| > | > bug in `configure.in'. Must we be bugward compatible?
| > | bugward :)
| > |
| > | I think so, cf. below.
| >
|
| > | > 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:
|
| This would be OK, but my understanding of your sentence "set host to
| host_alias at the end of the handling of the options" indicates the
| opposite.
I think our disagreement comes from the fact that I used `host_alias'
in the sense of my patch, and you read it in the sense of 2.13. in
the sense of my patch host_alias is the argument of --host. Therefore
`host=$host_alias' after options processing is just the same thing as
before: host is set to the arg of --host.
| What I was actually talking about are configure script containing
| things like this:
|
| AC_CANONICAL_HOST
| case $host_alias in
| sh-rtems*) ...
| i386-rtems*) ...
| i386-linux*) ...
But this soooo wrong! This is totally incorrect: host_alias is not
the right variable to check for a specific system!
| AC_CANONICAL_HOST
| case $host in
| sh-*-rtems*) ...
| i386-*-rtems*) ...
| i386-*-linux*) ...
| ...
This is right, and works right with/without my patch.
| If you'd "set host to host_alias at the end of the handling of the
| options", then host would change its contents in comparision to the
| state we had with autoconf-2.13. Therefore I'd assume constructs
| like the ones above would probably break.
No, because `host' is correctly set by AC_CANON_HOST. Really, I think
we are not disagreeing here. I probably have not exposed properly my
patch: I am referring to the chunk starting at the end the option
processing and ending with AC_CANON.
| > I've looked in several packages
| > though. But really, it doesn't make sense to me to use $host
| > etc. with AC_CANON.
| [Typo? Did you mean "without AC_CANON"?]
Right, sorry for the additional confusion :)
| Using $host with AC_CANONICAL_HOST is a fairly popular construct
| (Cf. libiberty/configure.in, glibc2/configure.in).
Really, my patch has no influence at all on this.
