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. _______________________________________________ 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/
