Autoconf was never designed with programming in the large in mind -- it takes the view that people work with one package at a time. The package-framework component that tla uses was never intended to me more than a sketch of what is actually needed.
Autoconf might not have been designed for it, but it plugs into that role quite well. You can have several sub-projects that use the GNU build tools recursivley, a wonderful example of this is binutils, where you have gas, gdb, etc as seperate components, and in the top directory a Makefile that runs the sub-project configure scripts. More or less like multi-tree configuration scripts. I don't know about the package-framework, but I suspect that it is just a reinvention of autoconf/automake just cause it could be done; just like hackerlab is a reinvention of large parts of glibc. Sometimes it is better to bite the bullet instead of wasting time reinventing the wheel. It also saves headaches for all parties involved, be it people porting the program, or wanting to extend it. I suspect that some of the speed issues with tla are actually because of hackerlab. Stuffy like using a totally unoptimised strcmp comes to min. Part of the political problem is that the FOSS community has lost (mistaken for solved) the problem of constructing a "complete GNU system" (or something morally comparable). The vendors and Debian have taught people to think of each upstream project as separate -- to think of the harmonizing of components into a complete system as "somebody else's problem". You speak of harmonising, but then I must ask you why the heck you wrote hackerlab (I'm only refering to the bits that the C library already implements) and package-framework, you don't harmonise a system by writing tools that the rest of the system doesn't use; you deharmonise the system that way. 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). 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. _______________________________________________ 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/
