Tom> The first phase of autoconf relies on GNU m4 and perl. Tom> Increasingly, in practice, it relies on automake and libtool. Tom> While jocularly dismissed in the autoconf documentation, the Tom> circular dependency between m4 and autoconf is a clear Tom> bootstrapping bug.
Alfred> I fail to understand why this is a bootstrap bug, yes, there Alfred> is a circular dependency there, but not one that causes any Alfred> grief. As compared to some weirder ones--GNU ada anyone? Alfred> You'd also have a circular dependency in package-framework if Alfred> it gets used, consider the shell starting to use it, then you Alfred> need a shell to configure the shell, and viola, circularity. Alfred> Basiclly, you can't come around circular dependencies for Alfred> this type of thing, and I don't consider it a serious Alfred> bogisity. For things that produce architecture dependant Alfred> output (compilers) this is far more important though. Ok, so, I have to say why the circularity is a bug and why it isn't necessary and in the course of that I'll add some "things we should be doing". I spend some of my time thinking about forseeable disasters and what they imply and how to be prepared for them. "Continuity of operations", "emergency responses" --- I eat that stuff up. A frequent source of agitation for me, these past couple of years, is the pitiful state of my first aid kit as supplies expire or get used up and I can't afford to restock. Don't call me a Boy Scout (those homophobes) but there are some values and priorities in common there. One shouldn't count on having much of a working, trustworthy computing environment when one needs to do an emergency bootstrap with little or no help from the (likely largely devastated) net. We really want lots of edge nodes to be able to come back on their own, presuming such things as heavily compromised binaries on what they've got that's still running. No, really. Stop laughing. I'm deadly serious. The good news is that maintaining that level of operational paranoia, done right, can have so many pleasant side effects on a day-to-day basis that it can more than pay for itself. One example dear to my heart is pedagogy -- a clear bootstrapping path, maintained and renewed across time, requires/enables students learning/rebuilding the stack from bottom to top. Another example: it helps us guard against emergent effects of a stack that slips out from under control. (While the Y2K bug, well, wasn't, the difficulties people had in making that so and preparing in case it was so are instructive -- we saw a generational crisis there). The circularity is a bug on principle and in forseeable, time critical, life critical practice. What happens when the cycle breaks? When someone needs to get stuff working but is faced with a busted shell /and/ a busted M4? An only slightly exaggerated analogy from a long-ago mentor concerns the state of metallurgy. If we lost access to steel refineries (he claimed and I believe him), we'd have to reconstruct a lot of historic metallurgy just to be able to build equipment heat-tolerant enough to use in making steel. And it's not like it's that damn hard or expensive. You pick a bootstrapping environment above which applications reside and below that you build a tower whose foundation is the raw-iron-du-jour. It's a question of building Stuff That Works and can be maintained, human-scale, generation after generation /as opposed to/ stuff that that just takes the earlier work for granted and hopes for the best. New Orleans vs. Amsterdam. You mention compilers -- well, don't get me started on that. It's a glaring flaw of the GCC project that it neglects the bootstrap path. Gimme an environment I can print in a small book and "toggle in" -- forth-ish say (something I respect about some Sun hardware). Then a tiny K&R-ish, non-optimizing C on that. Then a tiny, simple compiler that's enough to bootstrap GCC in that C subset. Then we're in business. Other towers are possible and worth considering, of course. Alfred> I still have problem to see how the two phase thing Alfred> [with autoconf] is a problem. The GNU project's success would hardly have been impeded by treating a GNU shell (not necessarily bash) and GNU Make as prereqs for everything else. Autoconf is almost entirely justified in its origins by not doing that. Most of the remaining justification could be eliminated by floating a nice portability library rather than trying to juggle libc variants. If Autoconf were never anything more than the tool used to build a GNU shell, GNU make, and maybe a portability library, I would have far less reason to complain. -t _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
