On Fri, Aug 12, 2005 at 11:33:40AM -0700, Claus Assmann wrote: > > I think the point is, that instead of guessing, what an OS supports, > > the makers of the OS shall say, what they think they support and you > > only test for their claims. > > How?
Look at what X11R6 did over all the years. imake was exactly about that, a single configuration file for the *vendor* to provide. > Is there something better than autoconf? That's the wrong question. > My configure script tests of course whether a feature actually works > as much as that is possible. It would be different from 95%+ of all configure scripts. Just to name a few typical examples of incorrect autoconf use (in combination with the rest of the GNU chain): (a) libtool contains operating system specific magic in ltmain.sh, which can easily be replaced by newer versions without hassle. But it also duplicated part of this magic in libtool.m4, which gets embedded into configure, normally approximately three times. This is not a problem for most programs, but some decide to alter their behaviour based on whether shared objects are supposed to be supported or not. A good (bad) example is sudo, which doesn't build the exec LD_PRELOAD wrapper on DragonFly without patching configure. (b) pkgsrc's bootstrap checks for the existence of sys/statvfs.h and statvfs(3). It uses the former if found and emulates the latter if not found -- but it still tries to use sys/statvfs.h, even if it conflicts with the compat definition. Sure, the problem here was DragonFly's fault having an incomplete implementation, but the configure behaviour nevertheless is broken as well. (c) how many configure scripts check for one behaviour and ignore the rest of the check? Xorg decided to move to autoconf for the modular tree, net result is a huge increase both in build time and distribution time, simply because it needs CPU hours to run all the autoconf scripts and the space they occupy in all the packages. IMO it's a real regression. Testing for *special* features is OK, but it has to be done carefully and doing it in almost any program is simply a pain in the ass. This completely ignores broken tests and compatibility problems not checked for. Just look at how many programs still want to include malloc.h or define malloc themselve. Same for errno. Both are locations specified 15 years ago by ISO C90, but do you really believe the stupidness has gone away over all that time? If any (old) platform still exists, which doesn't follow this basic requirements, why isn't that checked by autoconf and worked around *correctly*? There are guides for Linux which even hint adding your own malloc prototype for portability -- resulting in quiet the opposite behaviour. Joerg
