[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: current glibc vs debian sid

From: Franz Sirl
Subject: Re: current glibc vs debian sid
Date: Wed, 23 Oct 2002 12:21:13 +0200

At 09:50 23.10.2002, Akim Demaille wrote:
>>>>> "Franz" == Franz Sirl <address@hidden> 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'm fine with removing it completely now.  Autoconf is full of `FIXME:
remove when...'.  I'm fine with doing this in the release following
the next one.

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.

Franz> What always puzzles me on that issue is what is so difficult
Franz> about deciding whether we have a cross or native build? After
Franz> setting $canon_build, $canon_host and $canon_target (I'm using
Franz> the canon_ prefix here cause the naked $build, $host, $target
Franz> are documented as deprecated) the decision is simply:

Franz>          if "$canon_build$canon_host" ==
Franz> "$canon_target$canon_target" cross_compile=no else if
Franz> "$canon_host" == "$canon_target" cross_compile=simple else
Franz> cross_compile=canadian fi fi

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.

in the end, everything amounts to: 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. 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.

And, looking at the old syntax, it's biggest advantage was that you could use the same syntax for a native build and for a simple cross build, greatly simplifying scripts and tools like rpm. Overall it seems like a regression in usage simplicity, so a change of the coding standards by the GNU people may be unlikely...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]