On Wed, 23 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <hgs@xxxxxxxxx> 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
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
