Hi Alexandre,
Thanks for having spent some time to summarize the situation. When a
topic is beaten to death like this, we really need some summaries from
time to time.
Before anwering, let me recall a few constraint we face with Autoconf
(I know you, Alexandre, know them fairly well).
Basically, the only real hard limit we have are options. No old
options may become an error, no new options can be introduced,
precisely because of AC_CONFIG_SUBDIRS and (Cygnus') Configure (I
think its name is exactly Configure, and I will keep this
capitalization to distinguish it from Autoconf's product, configure).
This eliminates any --Host, --xhost, --cbhost etc. In addition, I
would have struggled a lot against --host and --xhost, because IMHO
--host is the right name, and it is not right to move the right
semantics to a wrong name. I would have OK with --cbhost, because I
really think it is the people who want the old behavior who should do
an effort, not the converse.
Another constraint, not as hard but still fundamental IMNSHO, is that
configure scripts should totally similar, because our goal is that of
the least surprise. So I'm against AC_ENABLE_OLD_SEMANTICS: I would
prefer to pollute Autoconf with old rubbish in all the cases, than to
see packages behaves differently with the same set of options.
Another constraint, which I do classify as less important than the
previous one which was less important than the first one, is that we
must keep configure scripts from different generations of Autoconf as
similar as possible. This is one face of the backward compatibility.
But this time, IMO, we must take the freedom to break what was wrong
to settle a better world.
We do face one of these situations, and it is perfectly normal that
there are partisans of the brand new world (I'm one of them), and
people who are first concerned with what the changes apply (I feel
close to them too).
Now let's answer you mail:
| Currently, GCC, GDB, GNU binutils, newlib and a couple of other
| packages all use variations of the same top-level `configure' script,
| which is not autoconf-generated, and was developed initially by Cygnus
| ages ago.
|
| This `configure' script figures out all of --build, --host and
| --target, based on what the user specified in the command line, and
| passes these three flags down to sub-configures, regardless of what
| the user has specified (but based on the supplied values, of course).
| For certain sub-directories, that are supposed to be built for the
| target, using the compiler created for the host, `configure' is run
| with --host=$target_alias.
I think we are misunderstanding ourselves, and it might well be
because I don't know enough what the Cygnus customers are likely to
do, and not to do.
Today, my favorite solution is still an option
--with-old-host-semantics or whatever the name. First, technically it
is sound: old configure scripts will not understand them but not choke
and them, and they will pass it to new configure scripts, so, IMHO, it
is a good solution.
You said it was bad because it implies a lot of changes of scripts and
documentation (which *must* happen anyway. I don't have the GNU std
handy, but according to what you say, we will have to update them
too). What I don't understand is just why should the users be aware
of the existence of this option.
My basic assumption is that Cygnus' customers are only interacting
with Configure, and never with configure. Am I wrong?
If I'm right, I still don't understand why --with-old-host-semantics
is not a good way out, since it's invisible.
If I'm wrong, then I perfectly understand your concerns.
Forgive me, I'm struggling a lot on this issue, because once you went
out of the cave and saw the sun and the trees etc., it's hard to get
back and stare at shadows :).
Also, I guess something important for such a tree is to have
homogeneous generations of configures. Can't autoreconf handle this
properly? Because then we have another alternative: Configure
translates what the user said into the new --build, --host, and
--target, and we don't have to change anything in Autoconf itself.
This is a much better solution, naturally, but it is not viable, then
--with-old-host-semantics seems fine to me.
| Please understand that, since we're talking about several different
| GNU packages, that the *user* may choose to combine as he wishes,
| making such an incompatible change is a losing situation: there's no
| way for a single top-level configure to accommodate them all, unless
| it analyzes each configure script, before running it, to tell whether
| it should use the old or the new behavior.
My two proposals answer those concerns, I think.
| > Cygnus (which seems to be the entity affected most by this change)
|
| I'm not sure I agree with this statement. It's true that Cygnus would
| be very seriously affected, but so would any GNU/Linux distributors,
| and most toolchain developers and power-users.
The solutions I proposed seem to apply, don't they?
Maybe autoreconf will require more work on it, but I'm ready to handle
it.
Akim
