Re: RFE: configure -> dependency list on exit.

[Paul Eggert]

Hugh Sasse Staff Elec Eng <address@hidden> writes:

> I'm proposing that Autoconf tell me as much as possible when things
> go wrong.  "Possible" includes knowledge that the authors of a
> configuration have.

But typically the information that the authors have is quite limited,
compared to the set of configurations out there.  And often the info
is wrong, or it becomes obsolescent so quickly that it's wrong by the
time the user runs "configure".

For example, the latest stable version of GNU Autoconf (2.59) says it
require GNU m4 "version 1.4 or later" but this is incorrect; it
actually requires 1.4.2 or later, even though m4 1.4.2 didn't come out
until after Autoconf 2.59 came out.  The problem is that m4 1.4 and
1.4.1 had serious bugs that break Autoconf, a problem that wasn't well
understood when Autoconf 2.59 came out.  This sort of situation is all
too common.

And even if the Autoconf authors had clairvoyance and knew that 1.4.2
would be required, it's not the case that people really need 1.4.2 all
the time; they can get by with a patched 1.4.  (Debian stable, for
example, runs with a patched 1.4.)


> But we can say that you need GNU m4 to build some packages, and GNU
> make to build some, etc.  So that level of dependency information is
> expressible.

It's expressible, but is it reliable?  Many non-GNU suppliers are now
supplying GNU features.  For example, Sun has added many GCC features
to its proprietary compiler.  And the BSD folks have added most GNU m4
features to their m4 -- they're not able to run Autoconf yet, but they
may get there soon.  And the BSD folks have also added several GNU
diff features to their diff.  I'm sure this list is not exhaustive.


>> (Perhaps I'm being overly pessimistic.  But in that case you can prove
>> me wrong by supplying a working implementation with some examples of
>
> Even that Patent Office don't make that demand except for things
> which are physically impossible. :-)

It's not an issue of physical impossibility here, so much as I'm not
sure exactly what you're asking for, and I worry that we'll find that
what you're asking for isn't feasible or useful or whatever, and that
the only way we'll find out what it is, and whether it is practical,
is by trying to design and implement it (and perhaps failing), and
that this will be a lot of work.  I sense that nobody else is jumping
up and down to volunteer to do this work, and I'm afraid this means
that if you want it done you're going to have to be the one to do it.