>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Today, my favorite solution is still an option
>> --with-old-host-semantics or whatever the name.
Alexandre> Assuming the user would know when to use this flag. As
Alexandre> I've written before, any solution that requires new flags
Alexandre> just won't cut it.
My proposal did not imply users had to pass it themselves, only Cygnus
configure would have.
>> What I don't understand is just why should the users be aware of
>> the existence of this option.
Alexandre> Because the intent is to move to the new semantics as it
Alexandre> becomes well-established.
Yes, definitely. What I am saying is that Cygnus configure could
fairly well be the air-bag which will make the interface between old
and new semantics. This Cygnus configure can display all the warnings
that you suggested that Autoconf configure does. All Cygnus
configure, or even Autoconf configure actually, need, is a means to be
sure the next subconfigure will understand it properly. Two ways:
either it knows that because it was under the responsibility of the
maintainer of the tree, in which case autoreconf is the tool, or
because the top configure passes a token to tell sub new configures to
behave like the old ones, i.e. --with-old-host-semantics.
Alexandre> We don't want to have Cygnus' configure to keep running
Alexandre> sub-configures with this extraneous option.
We can have this option being extremely verbose and complaining.
Alexandre> Moreover, the very fact that a new option is required may
Alexandre> cause things to break in case an old top-level `configure'
Alexandre> is used with new sub-configures: it won't pass down the
Alexandre> option to enable backward compatibility, so the user loses.
Well, I was definitely referring to the Cygnus' case, because that's
probably the largest trees we will ever find, so that's probably where
it is more likely to have momentum (definitely not a critic, just a
statement). In the other cases, I think it is not unreasonable to
have people autoreconf.
>> My basic assumption is that Cygnus' customers are only interacting
>> with Configure, and never with configure. Am I wrong?
Alexandre> They should be free to interact with configure too.
Alexandre> Let's stop talking about Cygnus' customers: we're talking
Alexandre> about people building GCC, GDB, binutils, etc. Those will
Alexandre> *usually* be interacting with the top-level configure, but
Alexandre> they shouldn't have to.
If they start doing tricky things such as running sub configures,
they might be old enough to understand and use the new --host options,
IMHO.
>> If I'm right, I still don't understand why
>> --with-old-host-semantics is not a good way out, since it's
>> invisible.
Alexandre> It is not, because it requires a top-level `configure' that
Alexandre> generates it. The user is no longer free to mix-and-match
Alexandre> releases of the programs cited above.
Yes he can! Only the top configure should do that.
>> Also, I guess something important for such a tree is to have
>> homogeneous generations of configures. Can't autoreconf handle
>> this properly?
Alexandre> The user has never been required to have autoreconf.
I had not understand the user herself was able to build the tree, I
thought you shipped tree. Is there any chance to read a document
which explains this all? I still have to guess too many things to
understand who is likely to do what.
Alexandre> Please tell me what is the problem you see with the
Alexandre> solution I proposed, bearing in mind that it is temporary.
Alexandre> I won't accept arguments that it is too complicated: you've
Alexandre> seen the patch, it introduces just 4 lines of code.
Yes, it is too complicated :)
Yes the patch is not too large, but that's not the point: there are
many `if and not if then else' which completely lose the mind. But
OK, the user is not supposed to use this. The result is the same
anyway: for instance we keep the confusion between host and build.
I'm terrified to see that build is sometimes the default for host, and
at other moments, it's the converse!
The problem I have with the solution you provide is that it destroys
what we want: a clean semantics. It destroys the interface we want.
So yes, it is transitory, but transitory back to where we are coming
from.
There are so many `temporary' buildings in French schools, I've been
so cold in so many of them, that I somewhat developed an antipathy to
transitory stuff. Let's go straight. It will hurt more, but it will
be much shorter, so on the long run, you win.
All I'm asking is a means to preserve the new semantics and the new
interface. Today's proposal kills it in favor of what we want to drop
dead.
I'm still looking for a solution which makes it possible to *tell* you
want the old stuff.
Alexandre> BTW, I've realized that we may need some additional kludge
Alexandre> to detect cross-compilation in case only --host is
Alexandre> specified. In the past, autoconf would notice the compiler
Alexandre> is a cross compiler and proceed under that assumption.
Alexandre> With the transitioning kludge I suggested, it would assume
Alexandre> a non-cross-compilation environment, and fail. When only
Alexandre> --host is specified, we should probably set
Alexandre> cross_compile=maybe, and the test of whether the compiler
Alexandre> is a cross-compiler should take this into account, and
Alexandre> determine whether cross_compile should be yes or no. Not a
Alexandre> big deal, but it seems important to me.
`cross_compiling=maybe'
I think you said it all. We want no maybe. No kludge.
Akim
PS/ I am not criticizing Alexandre. The solutions he proposes are
technically sound. They are the result of a long run thought about
the dilemma new vs. old.
