From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 4 Feb 2008 02:49:17 +0100 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] A newbie question... Message-ID: <20080204014916.GE15093@nibiru.local> References: <3e3428848ec2d125923fc97232534973@quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e3428848ec2d125923fc97232534973@quanstro.net> User-Agent: Mutt/1.4.1i Topicbox-Message-UUID: 42ce789a-ead3-11e9-9d60-3106f5b1d025 * erik quanstrom 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/ ---------------------------------------------------------------------