From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3e3428848ec2d125923fc97232534973@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat,  2 Feb 2008 15:10:50 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] A newbie question...
In-Reply-To: <acb195480802021122t2ed0c4d1j823c505141eb4531@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 406f0bfa-ead3-11e9-9d60-3106f5b1d025

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