> 
> 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

Reply via email to