Re: [9fans] A newbie question...

[Enrico Weigelt <weigelt@metux.de>]

* erik quanstrom <quanstro@quanstro.net> wrote:

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

Actually, often for problems that don't exist at all
(on sane systems). For example, why each individual package
should check for the toolchain commands ?! That's completely
insane! There are standard variables for that, which can
be assumed to point to the right commands. Checking if the
toolchain's not broken should clealy NOT be the job of an
individual package.

Another point are imported libraries: there's really no need
to run any compile test (or even worse: try to run some code).
Just ask an database tool (->pkg-config) to tell you the right
flags and make sure the required version is installed.
Yeah, there are working autoconf macros for that, but many
many packages still don't use them (sometimes with really
stupid cop-out's ;-o)

Older versions of autoconf had been even more insane:
Lot's of "detection" macros (X11 stuff was such an bad
candidate) pulled in hard-coded and absolute (!) pathes.
It's obvious that this clearly breaks any crosscompile attemt.

BTW: one thing I never understood in the autoconf world:
Why's the term "support" so badly abused ?!
Imagine: in many packages you can switch whether some other
package is used - they call this "supported".
For example I'm currently compiling VLC: there's an flag
for "gnutls" support. WTH shall this mean ?!
The right way would be an "enable TLS" option, stating this
requires GNU-TLS as dependency.
Seems like autoconf people tend to turn things upside down ;-O

> 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 already said: autoconf has *NOTHING* to do with real
portability, just working around lots of system/target
differences. ACK, this is really 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.

Well, I'm really happy with those optimizations (eg. on
number crunching applications, properly optimized code *can*
give an heaviy boost). But there's really *no* need for such
an complex and unstable oracle like autoconf - there are clean
ways to fix this, eg. passing the right CFLAGS and using the
compiler's/preprocessor's symbols.

> one last gripe: autotools often take longer to ./configure
> than to compile with gcc.  curious that gcc is famed for
> slowness.

Yep, *rofl* ;-O


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------