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
does.
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.
See http://wiki.linuxfromscratch.org/alfs/browser/alfs-POC/src/parser.c
The two main benefits are speed improvements and the ability to drop a
dependency.
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
ground.
[snip]
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
necessary?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
