Re: current glibc vs debian sid

[Akim Demaille <akim at epita dot fr>]

| At 09:50 23.10.2002, Akim Demaille wrote:
| > >>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
| >
| >Franz> Well, besides the coding standards problem, the main problem is
| >Franz> that you can't emulate the old syntax with the new syntax and
| >Franz> that the emulation of the old syntax isn't working
| >Franz> correctly. So either the old syntax compatibility has to be
| >Franz> fixed or it has to be rejected completely and the coding
| >Franz> standards need updating then.
| >
| >An incredible amount of time was spent in trying to maintain some
| >backward compatibility.  Some of us were against it, others wanted it,
| >even broken in some subtle ways.
| 
| It's not broken in a subtle way, it's heavily broken because the old
| syntax always forces a cross-compile setup right now. So removing it
| completely and updating the GNU coding standards would have been the
| better choice IMHO. Keeping an option, but needlessly changing it's
| semantics is the worst possible choice here.

I agree with you.  But that's not enough to remove it completely now.
It is much less broken that you pretend it to be: it does fulfill the
need of some people.  That it does not address everybody is known, and
this is why the code is scheduled to be removed.


| >Franz> Fixing the new syntax requires a documented way to set
| >Franz> $host_alias and $target_alias for a native build without
| >Franz> triggering a cross-compile (doesn't auto-set $program_prefix,
| >Franz> $ac_tool_prefix, etc.).
| >
| >What's wrong with ./configure --build=foo?  This is a native build on
| >foo for a native compiler.
| 
| But this doesn't set $host_alias or $target_alias and regardless
| whether you build native, simple cross or canadian cross, you'll
| always use $target_alias in Makefile fragments (GCC as the most
| prominent example) to setup pathnames and binary names. But now there
| is no longer a way to setup $build_alias==$host_alias==$target_alias
| without triggering a cross-compile. This functionality needs to be
| restored for native builds in a documented way.

I don't think so.  You might be asking for a new feature, but today
foo_alias corresponds exactly to what the user typed.  People have
been asking for this.  Now, if you want something like
foo_default_alias, I'm fine, I can install one.  But we won't go back
to changing the meaning of foo_alias now that it is clear.


| >It's not that simple.  Some people had argued that for instance
| >because of some libraries, something that looked like a native build
| >was actually cross.  Some people also said that they want to pretend
| >they cross-compile using their native compiling suite just to be able
| >to exercise their package in cross-compilation.
| 
| Well, I think you are sacrificing simplicity of the default path to
| handle some obscure setups that would be better suited with a separate
| switch like --enable-cross=no/simple/canadian. It's easier to document
| and easier to implement.

It didn't appear to be required, and I am still not convinced.
Anyway, the compatibility with some trees with mixed configure
versions was a requirement too.

As of today, configure --help is clear enough.

| System types:
|   --build=BUILD     configure for building on BUILD [guessed]
|   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
                      *************
|   --target=TARGET   configure for building compilers for TARGET [HOST]



| > we do not want any form of educated guess from configure: with
| > --host it's cross, without, it's not.
| 
| You are kidding, or? Currently autoconf "guesses" that it needs to use
| $ac_tool_prefix if $host_alias is set, it "guesses" that it needs to
| set $program_prefix if $target_alias is set and all this can happen
| even though autoconf happily reports "Checking for
| crosscompile... no". So effectively you only changed the preferences
| of the guesses.

I can't disagree with you on this one :)  Nevertheless, in the precise
case you are referring to, you still have total control on the value.
It's just that the default values reflect the most common setting:
they don't forbid others.  That was the case for the other variables.


| What is wrong with a flag like $cross_compile that is guessed by
| default but can be overridden with --enable-cross? And then this flag
| should be used throughout in autoconf to key decisions whether to set
| $ac_tool_prefix/$program_prefix/etc to some alias or not.

Nothing is wrong in this.  But that was not suggested when the move
was done, and it didn't appear to be needed.  Plus, (a similar
suggestion was actually made), the cross-compiling people didn't like
it as it required changing many scripts.