I think that you have misunderstood my purposes. I have never implied or suggested that a pure bash approach should be or must be or (whatever) be followed
religiously to a point where an automated method for building LFS should exclusively rely upon it. I just used it because your work seemed challenging towards
that direction. In more than one occasions I have said that this was simply an experiment, nothing more, nothing less. Having more books based on LFS will
eventually lead to such a break - up from the main LFS/BLFS core that I doubt it should be necessary to have ONE tool for building everything. In any case, some
clarifications must be made regarding intentions/directions/whatsoever:
1. jhalfs suits its purpose. When I originally started writing down the xml - "parsing" script it was mainly out of curiosity, and not an actual *need*. The
reason I do not like / use the nALFS way is the way it works: you actually use a re-written part of the book, simply rewiring xml source from the LFS book. Bash
alone can get everything included within (<element>, </element>) pair in about 30 - 40 s within the ENTIRE book (ie also the chapters not necessary for building
it). Do check previous posts in the mailing list and you will understand how. Some argued about not being able to have the <screen ...> ability too so that
nodump elements are also taken under consideration. That is complete now, so what? Next you will ask about xpointer/xpath like features. This can be done too.
In the previous post I made, there was a semi complete "parsing" method concept, that actually did one simple thing: print out in the screen either data
contained within the (<,>) character pair (grammar specific for xml) separately from data contained within (>,<) pair, which actually conceptually solves all
issues you have with TRAC too (I read the code you posted in your newest post Jeremy, i do not see any <,> and >,< pairs divided there, this could help you out,
I think). "Parsing" is then applied for any "data" contained withing (<,>) pair, where everything is easier because of the way the XML reading keys work. This
an interesting way to go with any parser to be used (if anything like this should be coded for the alfs project instead of reusing code from a third party
source). If bash does it for the entire book in about 1 (one) min, why shouldn't C do it much faster... So to end this definitely, please read the latest script
post, i believe that it has conceptually what it takes. That said, I am done with this. I intend to use x2sh concepts within personal bash scripts I use for
working with xml based logs. Scripting is only a quick and dirty way to do simple things. It is not meant for running Deep Space 9 on its own.
2. In a few words: bash may be T-Complete (heh heh, :P) as a language, but it is _NOT_ suitable for the general purpose of this project at all. It would make
the bash script so cryptically coded that newbies would be scared off anyway, while the more advanced users would not play with bash because of its _evident_
limitations. The jhalfs method is an insanely smart configure - like script and nothing more. This is why it serves its purpose so well. Sticks to KISS - like
principles. No one can beat that. Had it been a script - based approach only, I would have initially started this "script" based approach in Ruby, but bash is
good too. "Porting" code rather than concepts to another language is like duplicating the work, the bugs, the debugging process...
3. I am not going to enter the best - language - in - the world war here. It is counter - productive. If professional - level project management is applied to
the ALFS project, you will end up stemming another distribution, further parting away from the project's initial scope (ie educational). An object oriented
approach would be the best to follow, so whatever you will end up choosing, if it does not have OOP mentality, you will end up reinventing it within it.
4. Suppose you have what you need right now... LFSxml -> bash scripts -> installed binaries. It would be very tempting NOT to make a self - hosting distribution
out of this, especially since skills and sufficient motivation are present. Is this what you are actually after?
5. It seems only right to follow the DIY method in here too: talking much about a project is not the same as moving the project forward. I will just start to
code things for myself in C++ from a clean start; anything else but conceptual work would prove an obstacle more than a helping hand.
Thank you,
George Makrydakis
(gmak)
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
