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

[Andy Tai]

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 <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>