Seems some separate issues get mixed up together. Autoconf vs. package framework or hackerlab vs. libc--- not really related to the design and the future of revision control systems...
--- Thomas Lord <[EMAIL PROTECTED]> wrote: > 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 > Gnu-arch-users@gnu.org > http://lists.gnu.org/mailman/listinfo/gnu-arch-users > > GNU arch home page: > http://savannah.gnu.org/projects/gnu-arch/ > _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
