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

[Alfred M\. Szmidt]

   Alfred argues that Autoconf plugs into the role of a configure tool
   for "programming in the large" because it handles sub-projects.

   Eh.

I guess you haven't ever used it for something big (tla is quite small
in my opinion)

   Autoconf has climbed too far up the dependency stack (meaning it
   relies on too much other software).

Tom, you're smart, and I like you.  But stop being silly, autoconf
relies on less software than your package-framework (it relieas on awk
and printf in addition to the tools that autoconf relies on).

   Autoconf, at least as commonly used, is lousy at dependency
   discovery and awkward to control to override its defaults.

I disagree, --with-FOO=/dir/to/foo is quite flexible.  Far more
flexible than hard coding crti.o as you have done for unexec on
GNU/Linux platforms (did you know that the standard location for C run
time init object files is actually /lib on GNU/Linux?)

Infact, I think that normal users should simply use binary packages.
If you are a developer and wish to hack on something, it is trivial to
configure a program.

   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.

And package-framework does not fix any of that.  The way you solve it
with package-framework (from the looks, I only took a brief look at it
right now so I might be completely of base) is that you include each
library that is needed.  Say you have this little GNOME program that
needs some parts of GNOME, would you distribute the whole GNOME suit
just so that you compile the program?

Then there is the major deficency of tla using static libraries for
hackerlab.  Assume that you have a dozen programs using hackerlab, and
you find some security issue or what not in some function, you will
end up recompiling everything.  Simply out of the question when you
have a few hundred programs.

   Autoconf has also become notoriously bloated, etc.  It's never
   quite stabilized, even after all these years, which should at least
   make one suspicious.

Once again, I ask you to stop being silly, autoconf has been stable
since 2.50 when it got a huge overhaul.  GCC is in more flux.  It also
has less bloat than tla, which implements its own C library just cause
you happen to dislike libc for whatever silly reasons, while still
needing to link against libc!

   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.

Once again, you do not standardise something by inventing something
new.  I also fail to see what the exact hair in autoconf is, and I'm
far to familiar with autoconf.

   Alfred cites unoptimized strcmp as source of tla performance
   issues.

No I didn't, I said that it _might_be_ a source for some of tla's
performace issues.  If I had cited it as a source I'd provide a hard
numbers.

   by letting go of leadership on, for example GCC.

The FSF never let go of the leadership on GCC, they still are and
always have, been the leadership.  They just did some changes in how
it was exactlly managed (i.e. one person maintaining the whole thing
and getting loads and loads of bad patches, sound familiar?).

   The GNU project became entirely reactive and no longer proactive.

Might agree with that.

   I rely on plenty of tools that already exist and replace a
   relatively small subset with tools that have some advantages.

Instead of replacing (you're quite fond of that it seems) why not fix
them and add more advantages instead of doing complete rewrites?  It
will save both you (no need to rewrite the whole thing), and others
(no need to try and understand how your rewrite differs) times.

   The rx and vu components of hackerlib have served to great
   functional advantage over their libc counterparts.

My major grief with hackerlab is the rewrite of standard C functions,
strcmp, printf, ...  There are infact many nice things in hackerlab,
but the majority is just a silly rewrite of the C library for no
apparant reason.  Seriously, I really cannot understand how you can
justify a rewrite of something silly as strlen!  It just makes it a
hell for anyone who knows C to figure out how exactlly each new little
function behaves.

   I decide "make or take" questions rather deliberately, usually to
   good effect, and that kind of accusation, while common, irks me.

If it irks you, then the accusation must be true.