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

[Hugh Sasse Staff Elec Eng]

On Wed, 23 Feb 2005, Paul Eggert wrote:

> 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".

Well, if the package maintainers don't know how to build it, then
how is the end user supposed to make any sensible progress?
> 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

Then it is a bug.  I can't be expected to propose a system that can
never have bugs.  At least since executable code depends on this the
bugs should show up faster, which (like unit testing) is a good
thing.

> 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.

Yes.  And trying to second guess this sort of thing makes it worse.
At least if the software tells me something and it is proven
incorrect then it can be fixed, or I can point it at soemthing else
similar, etc.
> 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

But we have already agreed that we would be testing for features,
not version numbers, so if they don't have a patched 1.4 then
telling them 1.4.2 works would be useful information. Indeed, it may
fix other bugs in 1.4.1.  They might not have noticed 1.4.2 was
released.

> 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

If it is not sufficiently reliable to test for pre-requisites, then
why does autoconf exist?  I'm not asking for magic tests that
autoconf cannot do, I'm asking for known dependency information to
be incorporated where it can.  Where it can't we have the present
situation.

> supplying GNU features.  For example, Sun has added many GCC features

But their make is still poor.  So, you've already said we have to test
for 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

I'a asking for this only:
<quote>
5 people recommended that configure produce a dependency list at the
  end of operations.
</quote>
and I'm only asking the for minimal functionality that would help.
"The simplest thing that could possibly work" to quote XP.
The people who asked for this didn't even ask for package names. I'm
saying that where packages can be named they should be.  If the
information is wrong it can be fixed, but it will usually allow
people to make progress.  And people can ignore it if they have good
reason.  Diagnostics are never perfect, but where they exist they can
be helpful even when they are inaccurate.

> 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.

Yes, I probably will, but if I can't convince anyone of the utility
of this then there is no point in making the effort: were I to
present a patch, I would still have to explain it to convince people to
take the time to study the code.  If the idea should be killed, then
it should be killed early, because later will be much, much later in
this case because I am not familiar with the code base.

Furthermore, proposing it without working code at least allows
people to constrain the idea to something manageable, and allows for
the possibility that someone has already started work on this, or
knows how to do it and is keen to take it on later..
>

        Hugh