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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
