On Sat, Dec 08, 2012 at 02:05:57PM +0000, Christian Weisgerber wrote: > Marc Espie <es...@nerim.net> wrote: > > > I think this is worth a defect report to the autoconf people at the FSF. > > So, let me see, the value cached does not mean anything, because it's > > actually dependent on the list of libraries that are currently tested ? > > Yes, the test programs run by AC_CHECK_* are linked against $LIBS, > and AC_CHECK_LIB adds its library argument to LIBS on success. > That's the way it has always worked, by design. > That's the way it's always been broken. By design.
This obvious flaw was already apparent in the gap between autoconf 2.13 and the 2.50 release. Did they fix it ? Nope, instead the guys at the FSF (yep, Akim, you're one of the responsible parties) concentrated on making sure to rewrite a full lisp interpreter in m4. So, today, autoconf is still slow as hell, still mostly impossible to figure out, and still encourages copying bogus fragments from one configure.ac to the next. Oh hey, the changed the name of the file from configure.in to configure.ac. Do you think they could have fixed some glaring defects at that point ? heck, no, obviously not. The cached values still have haphazard names. Ways to enable/disable options are still half random (environment ? flag ? something else ?) and there's still no easy way to store the result of a configure run to *make sure* you can get the exact same options the next time, even if you install a new library. As far as all of these are concerned, there was exactly ZERO improvement between autoconf 2.13 and autoconf 2.69. And some people wonder why I hate the autocrap ?...
