> > So what are the facts to back up so many posts regarding autotools badness? > Just curious. >
part of the issue is that autotool solves a problem that doesn't exist on plan 9 systems. one doesn't need to test for compilers, exotic library problems or portability issues. (small rant: unfortunately, porting a lot of gnu stuff to plan 9 makes some sort of compatability goo necessary again.) another problem with autoconf is it encourages a style of programming that exploits every last nook and cranny of a system's & compiler's capabilities when the vast majority of applications will do just fine with the least common denominator. if one's goal is to run on a variety of unix systems, this just is poor engineering. as a case in point, my sacrificial linux machine is a 993mhz pIII. mplayer, an application one would think would benefit from fancy optimizations on such a slow machine, shows absolutely no visible performance benefit from sse2 instructions. it is fast enough already. imho, p9p and russ' unix extracts from p9p show a much cleaner way to port unix stuff. his method requires about 10 lines of system-specific stuff and about 75 lines of Makefile. one last gripe: autotools often take longer to ./configure than to compile with gcc. curious that gcc is famed for slowness. - erik
