On Jun 26, 2000, DEMAILLE Akim <[EMAIL PROTECTED]> wrote:
> (Cygnus') Configure (I think its name is exactly Configure, and I
> will keep this capitalization to distinguish it from Autoconf's
> product, configure).
Nope, the real name is `configure', and, to the best of my knowledge,
it pre-dates autoconf, and was an inspiration for it.
> Today, my favorite solution is still an option
> --with-old-host-semantics or whatever the name.
Assuming the user would know when to use this flag. As I've written
before, any solution that requires new flags just won't cut it.
> What I don't understand is just why should the users be aware of the
> existence of this option.
Because the intent is to move to the new semantics as it becomes
well-established. We don't want to have Cygnus' configure to keep
running sub-configures with this extraneous option. Moreover, the
very fact that a new option is required may cause things to break in
case an old top-level `configure' is used with new sub-configures: it
won't pass down the option to enable backward compatibility, so the
user loses.
> My basic assumption is that Cygnus' customers are only interacting
> with Configure, and never with configure. Am I wrong?
They should be free to interact with configure too. Let's stop
talking about Cygnus' customers: we're talking about people building
GCC, GDB, binutils, etc. Those will *usually* be interacting with the
top-level configure, but they shouldn't have to.
> If I'm right, I still don't understand why --with-old-host-semantics
> is not a good way out, since it's invisible.
It is not, because it requires a top-level `configure' that generates
it. The user is no longer free to mix-and-match releases of the
programs cited above.
> Also, I guess something important for such a tree is to have
> homogeneous generations of configures. Can't autoreconf handle this
> properly?
The user has never been required to have autoreconf. Of course, you
could tell people to re-generate all `configure' scripts with a new
autoconf, but, again, this would break their expectations. We need a
transitioning solution, not a backward-compatibility option.
Please tell me what is the problem you see with the solution I
proposed, bearing in mind that it is temporary. I won't accept
arguments that it is too complicated: you've seen the patch, it
introduces just 4 lines of code.
BTW, I've realized that we may need some additional kludge to detect
cross-compilation in case only --host is specified. In the past,
autoconf would notice the compiler is a cross compiler and proceed
under that assumption. With the transitioning kludge I suggested, it
would assume a non-cross-compilation environment, and fail. When
only --host is specified, we should probably set cross_compile=maybe,
and the test of whether the compiler is a cross-compiler should take
this into account, and determine whether cross_compile should be yes
or no. Not a big deal, but it seems important to me.
--
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
