Autoconf 2.5x

Stephen mentioned migrating to autoconf 2.5x, in response to my suggested configure.in patch to select the name of the DOC file. I took a look at what would need to be done to make that migration happen today. (It's Spring Break, after all; why go to Cancun and get in trouble when you can stay home and read autoconf docs, in between bouts of marveling at how cute your kids are?) Random thoughts: 1) Is anybody working on this already? If so, I might be able to help. I'm no autoconf wizard, but I have a solid understanding of how it works. 2) There are a few features of the current configure.in that don't look quite right. They are: a) There are two instances of AC_SUBST(docdir). (I mentioned this one already.) b) There is an instance of AC_PROG_YACC, but the result is not used anywhere. (I did a recursive grep to make sure that this is right; we really don't use the result of this test anywhere.) c) AC_HEADER_STAT does NOT appear in configure.in, but we check for STAT_MACROS_BROKEN in src/sysfile.h (STAT_MACROS_BROKEN is defined by AC_HEADER_STAT). On the other hand, all that sysfile.h does is #undef the offending macros, without offering any replacements, so maybe somebody removed the configure.in test on purpose. 3) I think a lot of the autoconf macro redefinitions in the current configure.in can be greatly simplified or even done away with, with a bit of elbow grease. 4) A bunch of the tests that check what kind of system you are on could be recast as standard autoconf tests, which check for some capability or feature of whatever platform you are on. This includes some of the stuff in the src/sys* files, but would require reworking some of that code. And wouldn't it be nice to do away with s&m entirely? And as long as we're dreaming, I'd like tenure and a Porsche... 5) BillP's recent note about HP-UX brokenness with respect to dlopen()/dlclose() reference counting made me think about adding tests for this to configure, which made me think about digging through libltdl (libtool) to see how they handle it, which made me wonder why we should go through all the pain of duplicating their work. 6) A lot of the stuff I mentioned above would cause random breakage on random platforms for awhile until it got exercised sufficiently to find all the brain damage introduced by trying to make things better. On the other hand, this is also an opportunity to clear out junk, such as the workaround for a broken zsh beta from 1996. -- Jerry James (<URL:http://www.ittc.ku.edu/~james/>)