Re: AARRRRGGH! Die Libtool, die!

[Tom Lord]

       > (Personally, I'd rather have all those tools (auto* included)
       >  written in something like perl -- it's nearly as ubiquitous
       >  and *far* more managable.  Of course perl couldn't use them
       >  then, but AFAIK, it doesn't anyway.)

       I would use Python myself, but otherwise I concur.

Bah.

Both perl and python are not stable.  `sh' hasn't changed much in a
decade and probably won't for another decade if ever.  `sh' is more
than adequate for the job.   If you must reach for something more,
especially on this list, for gosh sakes, pick something rooted in
stable standards: reach for SCSH, you traitors.

The problems with the auto* family of tools include:

        1) reliance on separate distribution

           Everything depends on those tools, and those tools aren't
           stable.  Build systems are an area where you want
           conventions, not dependencies.  It sucks that developers
           have to keep multiple versions of these tools around.


        2) wrong approach to application portability

           The portability problem these days is much smaller than it
           was when autoconf was conceived.  Feature tests are an
           inelegant solution that has, for the most part, failed
           (just try building a randomly selected set of public
           projects on anything other than a recent GNU/Linux system).

           A better use of everyone's time would be to work on 
           designing and stabilizing a portability library against
           which new applications could be built and to which old
           applications can be ported.


        3) wrong approach to /bin/sh portability (m4)

           The `/bin/sh' portability problem is much smaller today
           than it was when autoconf was conceived.   The role of
           m4 (GNU m4 specifically, no less) in autoconf has outlived
           its usefulness.   The obfuscation cost of the use of m4
           in autoconf now outweighs its payoff.


        4) wrong approach to makefile portability

           The `make' portability problem is much smaller today 
           than it was when autoconf was conceived.  The auto* family
           clings to requirement of makefile portability even while
           GNU make runs pretty much everywhere.


        5) wrong approach to makefile automation

           Roughly speaking, `automake' bridges the gap between
           historic versions of `make' and the capabilities of GNU
           make.   If you commit to GNU make, you simply do not need
           automake.


        6) lack of consideration for package management

           The functionality of package managers belongs in the 
           configure/build tools.


        7) excessive complexity

           I've scientifically measured it and the result is official:
           the auto* family is a gazillion times more complicated than
           it needs to be.   Of course, the battle-scarred maintainers
           of these packages will regale with you with horror stories
           about how each and every detail of the auto* family came
           into being -- but they'll also falsely ask you to believe
           that those stories justify making each and every free
           software project dependent on solutions to 20 year old
           problems that no longer exist.

        etc.

Oh yeah -- did I mention that my `package-framework' contains the
skeleton of a replacement for the auto* family?  I guess I must be
biased....

-t