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

[Alfred M\. Szmidt]

   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.