Jeremy Huntwork wrote: > Did I read you right, though, that you don't think a new alfs tool is > necessary?
Yes, that is what I was saying. However, your point about dependencies is something I didn't think about. For developers, it is a non-issue. I can't imagine an LFS developer not having libxml2 or libxslt on their system. It may be an issue for non-developer users, but IMO, not a major one. There are no required dependencies of these packages and the total build time is less than 2 SBU. If you want to practice coding in C (or any other language) and use ALFS as a vehicle, then that's great. I just don't think the project needs it. What it needs is polishing and enhancing an already excellent tool--jhalfs. The time for jhalfs is mostly in the xsltproc parsing. How often does the book change that you have to run jhalfs. Certainly not several times a day. In any case: [EMAIL PROTECTED] time jhalfs mkdir: created directory `/mnt/lfs/jhalfs' `/usr/share/jhalfs/functions' -> `/mnt/lfs/jhalfs/functions' mkdir: created directory `/mnt/lfs/jhalfs/logs' Downloading the LFS Book, version development... done Extracting commands... done Creating Makefile... done real 0m22.100s user 0m14.705s sys 0m1.352s Is all that effort really needed to improve a 22 second process that runs at most a few time a day? I'll also say that I do have a 3GHz system and slower systems will take proportionally longer. Please also note that I'm *not* saying to abandon the idea of a compiled system. If you have an itch, scratch it. I *am* saying that if I was running a commercial enterprise where I was paying a programmer, I wouldn't do it because it is not an effective use of time. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
