[geeks] What is going on with the open source community ...the stupid bastards are clueless

[Jonathan C. Patschke]

On Sun, 27 Apr 2008, Michael C. Vergallen wrote:

> A starting to wonder why the Open Source developers are so enamoured
> with the use of libtool, automake & autoconf.

Automake and autoconf aren't really all that bad (aside from their use
of m4).  They solve a very real problem in a needlessly kludgy[0] way.
However, they solve it in a less kludgy way than most other attempts to
solve that particular problem.  All of them are, of course, a poor
substitute for actually porting code to a new platform and centralizing
features in a way that allows for make to DTRT just by knowing uname and
what features the person building the package wants.

However, when you're time-constrained, sometimes a poor substitute is
better than not supporting a particular platform at all.

Libtool, however, used to be halfway decent a -really- long time ago,
when it was just a wrapper around the toolchain for building shared
libraries.  That is, before it started dropping its stupid '.la' files
into /usr/local/lib.  Outside of legacy platform support, it's quickly
becoming a dinosaur, though.  I can't think of a Unix-like platform
other than AIX that takes a radically different approach to building
shared libraries.  Everywhere else is just 'cc' with some magic,
followed by 'ld' or 'cc' with some different magic.  Those platforms
could be supported by a much less painful tool (or, *gasp* platform-
specific Makefile rules).

> They seem to think their model works... However try to compile a piece
> of software like cups on sun solaris with the NetBsd pkgsrc tree and
> you have to rework the whole ~ damn Makefile & reset all the options
> manually. because of the damn mess libtool makes by trying to use
> dylib and sutch while the writers of the package do not even use that
> peice of crud...I spend all night working on this fucking piece of
> shit while I could have gotten it build in  20 minutes using the
> normal method.

So....it builds fine "the normal" way, which is presumably from the
source tarball (which has the automake/autoconf/libtool cruft in it) but
not from pkgsrc?  How is this an autotools problem?

> Also when you tell them they don4t use pointers in the right
> way...they imsult you like you are a stupid bastard. They jsut write
> their code in a bad way and because it works for them with gcc they
> think it works on every system.

Oh don't get me started on that.  "All the world runs gcc" has caused me
more than enough grief on Solaris, IRIX, and AIX for one lifetime.
Sadly, companies like Sun, eager to have their platform (and toolchain)
work with every poorly-written piece of g-ware out there, rather than
investing the time and effort in submitting patches to these packages to
make the work on compilers that take a less liberal approach to
following the ISO C standards, have made their -compilers- less
rigorous.

And, yet, they tout this as a "feature".

The FSF are leading the entire industry on a campaign of "no compiler
toolchain left behind".


[0] Something that's always bugged me about autoconf is that there tend
     to be a great many checks it runs that could be batched rather than
     its current mode of building a tiny test case, running it through
     the compiler, and checking the result.  Why[1] check each library
     and symbol with an explicit link test?  It'd be much saner to check
     them all at once through the platform's interface to the dynamic
     linker (dlopen() or the local equivalent), and then test-link all
     the ones it found to verify that the linker works.  The same goes
     for all the sizeof() inquiries, and most of the preprocessor
     definition checks.  At least they finally implemented a cache a few
     years ago, and sometimes it even works!
[1] Actually, we know the answer to this one.  Since it's all a wrapper
     around a macro language and scripted in a shell, this is the most
     obvious way to generate the tests, the easiest to verify as correct,
     and probably the most easily maintained.  It isn't, however, the
     cleanest.  Why no, I don't have time to implement it this way, or
     I'd have already done it--I don't use autotools, anyhow.
-- 
Jonathan Patschke | "There is more to life than increasing its speed."
Elgin, TX         |                                   --Mahatma Gandhi
USA               |