[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] programming in the large (Re: On configs and huge s
Re: [Gnu-arch-users] programming in the large (Re: On configs and huge source trees)
Tue, 18 Oct 2005 16:45:18 -0700 (PDT)
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
> tool for "programming in the large" because it
> handles sub-projects.
> Autconf started off where it should have stopped as
> a handy
> bootstrapping tool for GNU development environments
> 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
> 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
> 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
> 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
> 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
> 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.
> Gnu-arch-users mailing list
> GNU arch home page:
Re: [Gnu-arch-users] programming in the large (Re: On configs and huge source trees), Thomas Lord, 2005/10/18