Re: [Gnu-arch-users] programming in the large (Re: On configs and huge source trees)

[Thomas Lord]

Alfred argues that Autoconf plugs into the role of a configure
tool for "programming in the large" because it handles sub-projects.

Eh.

Autconf started off where it should have stopped as a handy 
bootstrapping tool for GNU development environments on 
foreign platforms.  (There is a distinct problem that, if
you like robustness and control in your software stack, also
needs work which is a maintained bootstrap path on raw boxes.)
A tiny set of tools, needed for everything else, need to be
portable in that way but once you have those in place -- that's
where to stop.

Autoconf has climbed too far up the dependency stack (meaning
it relies on too much other software).

Autoconf, at least as commonly used, is lousy at dependency discovery
and awkward to control to override its defaults.   In other words,
it does sorta ok at looking in "standard locations" to find a
dependency but that facility doesn't seem to well-handle the case
when you have sibling source components in a tree being installed
in a non-standard place.

Autoconf has also become notoriously bloated, etc.   It's never
quite stabilized, even after all these years, which should at least
make one suspicious.

One thing I wanted to show with package-framework and hackerlib
is that you can standardize a package-combining system and use 
portability libraries and then you don't need autoconf's hair.
(Of course, hackerlib also has a lot of little nice things that
correct some historical baggage in libc.)

Alfred cites unoptimized strcmp as source of tla performance 
issues.  (a) *mostly* not.  (b) it is only because of low priority
(that *mostly*) that I have neither fixed/merged various patches
that optionally map the string functions to their native libc
counterparts or set up a framework for platform-specific
versions or spent any time on just the obvious portable C hacks
that would speed it up with most compilers.

> Basiclly the reason why GNU isn't harmonised is simply because it has
> always been maintained in a distributed manner, where tools were
> written on different systems, using different libraries, and what not.
> And not because of Debian and other vendors, they didn't exist in the
> beginning of the GNU project.  GNU maintainers also have a lousy
> communication between each others, many of them don't even read the
> GNU Coding Standards (and no, I'm not refering to the C syntax, I'm
> refering to not using artbirary limits).

The vendors and Debian didn't exist in the beginning, that's right.

Their arrival on the scene was shortly followed by contraction of
FSF-led efforts to build a complete GNU system, by an abandonment
of long-standing architectural plans, and by a quiet redefinition
of the project.   FSF scrambled to prevent disaster by fighting 
against things like (the then un-free) KDE and by letting go of
leadership on, for example GCC.   But these developments came at a 
cost -- the vendors, especially, seized the agenda.  The GNU project
became entirely reactive and no longer proactive.

> If you want to harmonise the system, start by using the tools that the
> system already has and not by writting your own version of them just
> because you `think it is cleaner', because it isn't.

I rely on plenty of tools that already exist and replace a relatively
small subset with tools that have some advantages.  Yes, for example,
I was too sluggish with a few patches making Hackerlib awkward on
on a tiny number of platforms but on balance it has greatly simplified
writing widely portable code.  The rx and vu components of hackerlib
have served to great functional advantage over their libc counterparts.

I decide "make or take" questions rather deliberately, usually to good
effect, and that kind of accusation, while common, irks me.

-t