On Jun 26, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
> However, as Akim has said before, it would be bugward compatible.
My suggestion is both backward- (or bugward, if you will) and
forward-compatible. I don't understand the reason of so much heat
about it. It's a 5-lines change that gives time for everybody, Cygnus
included, to adapt to the new behavior.
Let me try to explain why this is so important.
Currently, GCC, GDB, GNU binutils, newlib and a couple of other
packages all use variations of the same top-level `configure' script,
which is not autoconf-generated, and was developed initially by Cygnus
ages ago.
This `configure' script figures out all of --build, --host and
--target, based on what the user specified in the command line, and
passes these three flags down to sub-configures, regardless of what
the user has specified (but based on the supplied values, of course).
For certain sub-directories, that are supposed to be built for the
target, using the compiler created for the host, `configure' is run
with --host=$target_alias.
The whole point of this top-level `configure' script is that you can
throw in several different sub-packages, such as gdb, gcc, gas, ld,
libiberty, newlib, libgloss, tcl, tk, tix, etc, etc, etc, into a
single source tree, and have them all build with a single `configure
--flags; make; make check; make install'. The top-level configure
knows about dependencies between the packages, which ones should be
built for target and which ones should be built for host (and which
ones for both), etc. Moreover, it's supposed to be possible for you
to pick the sub-packages of a certain release of binutils, those of a
certain release of gdb or insight, those of a certain release of gcc,
and so on, have them all built in a single tree, test them together,
then install them.
Enters an incompatible change in autoconf. It requires the top-level
configure to no longer specify --host when it knows it's not
cross-compiling. Ok, so the top-level configure is adjusted so as to
pass only `--build' down, in this case. But then, old sub-package
configure scripts, from a previous release the user chose to use,
would not take --build as a default for --host; they'd use
`config.guess' to guess host. What if the user's specification was
--build=i586-redhat-linux-gnu, which would cause GCC to generate code
optimized for pentium, but, because --build is not used as a default
for --host, it ends up being guessed as --host=i686-pc-linux-gnu,
defeating the intention of the user's?
Please understand that, since we're talking about several different
GNU packages, that the *user* may choose to combine as he wishes,
making such an incompatible change is a losing situation: there's no
way for a single top-level configure to accommodate them all, unless
it analyzes each configure script, before running it, to tell whether
it should use the old or the new behavior. And then, there's always
the risk that the user chooses to use, as his top-level configure,
that of an old release, that passes down both --build and --host,
ending up with wrong assumed results because some of the packages'
configure scripts decided not to test for certain features because
they assumed a cross-compilation environment.
Can you see that this is not a Cygnus-only issue? It has the
potential to make the lives of several serious GNU developers a pain.
It's almost impossible to work around the problem in Cygnus' top-level
`configure', which is used in so many GNU packages. We really need
help from autoconf to make the transition as little troublesome as
possible.
> Cygnus (which seems to be the entity affected most by this change)
I'm not sure I agree with this statement. It's true that Cygnus would
be very seriously affected, but so would any GNU/Linux distributors,
and most toolchain developers and power-users.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
