[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why was handling of program_prefix changed?
From: |
Ian Lance Taylor |
Subject: |
Why was handling of program_prefix changed? |
Date: |
11 Jan 2002 19:56:55 -0800 |
(I'm no longer on the address@hidden list; please CC me on any
replies.)
In autoconf 2.13, I see this code:
test "$host_alias" != "$target_alias" &&
test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
program_prefix=${target_alias}-
In the current autoconf CVS sources, I see this:
test -n "$target_alias" &&
test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
program_prefix=${target_alias}-[]dnl
Note that this is significantly different. In the old code,
program_prefix was set by default if host_alias != target_alias. In
the new code, program_prefix is set by default is target_alias is set
at all.
I believe the original version is correct. Suppose I am using an
automatic configurator which works over a whole tree, like the Cygnus
configure script. It is natural to always pass --host and --target
options. When those options are the same, it indicates a native
build, implying that the default value of program_prefix should be
empty.
The original logic was that program_prefix should be set by default
for a non-native build. That is what the original code tested for.
That code is based on the same code in the Cygnus configure script.
Why is it correct to set program_prefix merely because a --target
option was used?
Moreover, the code does not match the documentation. The
documentation describes the original behaviour, not the new behaviour:
If any of the options described below are given to @command{configure},
program names are transformed accordingly. Otherwise, if
@code{AC_CANONICAL_TARGET} has been called and a @option{--target} value
is given that differs from the host type (specified with @option{--host}),
the target type followed by a dash is used as a prefix. Otherwise, no
program name transformation is done.
The change was made with the following ChangeLog entry, which does not
mention this behaviour change:
2000-05-24 Akim Demaille <address@hidden>
The options --build etc. used to set `$build'. *If*
AC_CANONICAL_SYSTEM was run, then the value of `$build' given by
the user was saved into `$build_alias', and `$build' was
normalized using `config.sub'.
Now, let `--build' set `$build_alias' so that scripts with or
without `AC_CANONICAL_BUILD' have the same semantics. This allows
to use `AC_CHECK_TOOL' without requiring `config.guess' and
`config.sub' (which was bizarre anyway).
* acgeneral.m4 (_AC_INIT_PARSE_ARGS): --build, --host and --target
set `build_alias' etc.
After the option handling, set host to $host_alias etc. for
bugward compatibility.
(AC_CANONICALIZE): Mutate into...
(_AC_CANONICAL_SPLIT): this, which does not canonicalize, it just
computes `$foo_os' etc.
(_AC_CANONICAL_THING): Remove, too confusing.
(AC_CANONICAL_BUILD): Adjust.
Do not assign any value to `build_alias', just compute `build', and
`build_{cpy, vendor, os}'.
(AC_CANONICAL_HOST, AC_CANONICAL_TARGET): Likewise.
(AC_CHECK_TOOL_PREFIX): Fire your rule when `$host_alias' is
given, not when `$host != $build'.
Here is a patch to restore the original behaviour:
2001-11-19 Maciej W. Rozycki <address@hidden>
* lib/autoconf/general.m4 (AC_CANONICAL_HOST): Don't set
program_prefix if target_alias equals host_alias.
autoconf-2.52-target_prefix.patch
diff -up --recursive --new-file autoconf-2.52.macro/acgeneral.m4
autoconf-2.52/acgeneral.m4
--- autoconf-2.52.macro/acgeneral.m4 Wed Jul 4 15:05:43 2001
+++ autoconf-2.52/acgeneral.m4 Sun Nov 18 15:27:47 2001
@@ -1774,7 +1774,7 @@ _AC_CANONICAL_SPLIT([target])
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
-test -n "$target_alias" &&
+test -n "$target_alias" && test "x$target_alias" != "x$host_alias" &&
test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
program_prefix=${target_alias}-[]dnl
Ian
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Why was handling of program_prefix changed?,
Ian Lance Taylor <=