On Jun 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> 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.
No, because each package comes with its own top-level `configure', so
the user would be forced to use some top-level `configure' that passes
down the correct options. Forget the Cygnus case for a moment: I'm
talking about users of GNU packages in general. Cygnus' problem is
smaller, in this sense, because it ships a single source tree to the
user, so it can easily be kept consistent (it's just a lot of work to
make the transition). I'm now worried about GNU users in general.
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.
What's the point? Since the top-level configure can't tell whether
some of the sub-packages would need the option, it must pass it in,
just in case. This is totally unreasonable. You seem to be throwing
in arguments into a problem you don't understand.
Please download the sources of GCC, GNU binutils, GNU GDB, for a
start, notice that they all share a common top-level structure, and
they all share some sub-directories, and each of them has some
sub-directories of its own.
Then, choose one of them to be your top-level source directory, create
links to all files and directories within the other trees, then create
a build directory elsewhere and run the top-level configure.
Now imagine some of the sub-packages require this
backward-compatibility flag you've suggested, but print a big warning
whenever it's used. Come back when you figure out a way for the
top-level configure to complete correctly, without causing any such
big warnings to be printed.
> 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.
It is totally unreasonable. GCC and binutils are bootstrapping tools
(i.e., you may have to build them before you can build anything else).
You can't require people to run autoreconf before they're able to even
configure them.
> I had not understand the user herself was able to build the tree, I
> thought you shipped tree.
Both GNU and Cygnus have always shipped source code. It's a strict
requirement of the GPL that the user must be able to build the
executable from the sources.
> 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.
Do you think the solution is any worse than what we had? I agree it
is worse than what we have now, in the CVS tree, but what we have now
is totally unacceptable from an evolutionary point of view. It breaks
backward-compatibility so badly that it goes against the agreement we
had, that the next release of autoconf would be compatible with the
previous one.
I had agreed with the change because I didn't realize it was breaking
it so badly. Now, that I do, I see we *must not* release autoconf
with that change. Being an improvement or not, it just breaks too
much stuff. We need a transitioning solution, from the old, arguably
broken behavior, to the new one, which we haven't agreed upon yet, at
least WRT --host implying cross).
What I've been proposing is to step back, look at what we had before,
and find a path that will take us from where we were to where we want
to get, whenever we agree on where we want to get. The only other
alternative is to just revert the patch that introduced the
backward-incompatible change and keep it as-is.
> 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.
Nope: it will enlighten people about the difference. The user will
get a warning indicating he shoud have used --build instead of --host.
For cross builds, he already had to specify --build and --host anyway
(even though specifying --build wasn't required, but it would result
in incorrect behavior in case `configure' actually depended on
$build). What I propose is an improvement over the status quo as of
the previous release, and one that will eventually take us to the
behavior we want.
> I'm terrified to see that build is sometimes the default for host,
> and at other moments, it's the converse!
Look at it from the perspective of the old behavior. Analize each set
of arguments to configure, and think whether the behavior is
surprising or might confuse new users in any of the cases. If you
find *any* such case, please show me.
> The problem I have with the solution you provide is that it destroys
> what we want: a clean semantics.
It doesn't destroy anything. We didn't have a clean semantics.
Moving into it in a backward-incompatible way is unacceptable.
Therefore, the solution I propose will actually give us the clean
semantics, it just takes a bit longer than you want. But it's not
essential that we clean the semantics now. The semantics of released
versions have been there for ages, and it's been confusing, but people
have lived with that, and some people are used to it. I'm proposing
some way to allow us to eventually arrive at some clean semantics.
Moving to an incompatible solution is far worse than that: people will
get in trouble, complain, ask us to revert to the old behavior, they
may even modify their own versions of autoconf to avoid having to
modify scripts they've accumulated over years, release their software
containing that modification, and eventually the whole `configure'
stuff will be a mess, because people won't be able to know how to do
what they want without looking at the `configure' script to tell
whether they should use --host or --build. That's why we need a
transition solution, with warnings getting printed: to give people
time to get used to the new behavior, to let them see that it is
better, to adjust their scripts and documentation. Breaking all the
hell lose just because it appears to be right is not the way to deal
with such an important piece of software. The change that was made
must be taken back. We now have to find some way to introduce it
without the potential of breaking so much code out there. The only
possible way is a long term transition, with a backward- and
forward-compatible solution.
> All I'm asking is a means to preserve the new semantics and the new
> interface.
My proposal doesn't break it. Well, ok, it breaks the `--host implies
cross' principle, that I don't support when host=build, anyway.
> Today's proposal kills it in favor of what we want to drop dead.
Today's proposal is a step towards it, from where we should be (which
is not where the CVS tree is, because we weren't careful enough to
analyze in depth the consequences of a very important change) to where
we want to be (which is where the CVS tree is).
> I'm still looking for a solution which makes it possible to *tell*
> you want the old stuff.
Any solution that triggers the old behavior based on an option won't
work. As you wrote before, we want only one behavior. Here's the
behavior I propose:
- build is the platform on which you're building the software
- host is the platform on which the software will run
- target is the platform for which the program being built (typicall a
cross assembler, compiler or debugger) should generate code
They all default to the result of `config.guess', unless you specify
either --build or --host. In this case, the default becomes the
platform you specified. If you specify both, and they're different,
`configure' will assume cross compilation is taking place, so it won't
run any tests that require execution. Target is assumed to be the
same as host, unless --target is explicitly specified.
Hint: if you mean to override the result of `config.guess', prefer
--build over --host. In the future, --host will not override the name
of the build platform. Also, when you only specify --host,
`configure' will assume cross-compilation if your compiler doesn't
seem to be working properly, instead of giving you an error.
It may not be as simple as target defaults to host defaults to build,
but I'm sure it is less surprising for people used to the old rules
and for people who don't clearly understand the distinction between
host and build.
> `cross_compiling=maybe'
> I think you said it all. We want no maybe.
We need that, because that's what we had before.
--
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
