[RFC] The Future of the ALFS project
jhuntwork at linuxfromscratch.org
Tue Feb 28 10:20:25 PST 2006
Bruce Dubbs wrote:
> George Makrydakis wrote:
>> Provided there is time on my side, I am available to start coding for
>> your project in C/C++/C#/Java (preference for C++ if in binary), I will
>> in any case complete the bash - based "parsing" approach, for it may
>> prove handy as a tool elsewhere in the project (support scripts). Also
>> with it goes a work for table structures in bash.
> Selecting the proper language for a project is an art. What is desired
> is to make things easy to code and maintain as well as provide for
> efficient execution.
You realize that George's comments above were about coding for alfs,
right? (At least, I think they were...)
> I have nothing against what George has done, but quite frankly, what he
> he has done is proven that bash is a Touring Complete (TC) language.
> What that means is that anything you can do in one TC language, you can
> do in another. I don't see any advantages over the jhalfs methodology.
> In fact, the books are written in xml using docbook. The purpose of
> xslt is to transform xml into another form. That's exactly what jhalfs
> Lets look at the issues.
I agree, mostly. Still, if I could get my C parser finished... I'm so
close it hurts! I just need to get entities parsed and add the ability
to parse the extra xpointer flags - this is a must for CLFS.
The two main benefits are speed improvements and the ability to drop a
Speed: Compare 1-2 seconds parsing time to 1-2 minutes. Yes, as you have
pointed out Bruce, when doing an entire jhalfs build, 1-2 minutes is
negligible. However, when you're developing, or testing an LFS build and
you use jhalfs several times to parse the book, that 1-2 minute wait
becomes annoying. At least it does for me.
Dependencies: This is probably the more important issue. How many people
like to be *required* to add libxml2 and libxslt just to parse the book
so they can automate the build?
In any case, this is all a side issue. The how of the parser isn't
currently as important as other jhalfs issues, or getting alfs off the
> To me the ALFS project is essentially complete for LFS. It can be
> extended to HLFS, CLFS, and BLFS using the same techniques if desired,
> but it does not need the same level of effort as the other projects
> where there is a constant churn of updated packages. It only needs to
> be updated if there is a significant change to the LFS book structure.
There are yet some functionality improvements that need to be made, IMO.
It should be more modular, and the code needs to be less dependent on
the specifics of the LFS book. I'd be very happy if jhalfs could take
the place of nALFS as the current ALFS tool.
Did I read you right, though, that you don't think a new alfs tool is
More information about the alfs-discuss