Greetings and a General Cleanup
georgeb at linuxfromscratch.org
Fri Nov 3 14:10:38 PST 2006
> El Viernes, 3 de Noviembre de 2006 14:39, George Makrydakis escribió:
>> M.Canales.es wrote:
>>> The new jhalfs code may be something totally different, thus the
>>> discussion is open to any one that would expose thier point of view.
>> Totally different. Does this mean that the C++ route is acceptable?
> Is acceptable for the long-time-waited-and-never-implemented new alfs tool.
> The issue is that I don't know C, C++, Python, PHP and like, thus migrating
> jhalfs to a non-bash/XSL based code will exclude me from its development.
As long as you have 2 free neurons able to make a connection you can
learn. Anyone who can make sense out of xsl transforms has the
horsepower to deal with C/C++. Being present at the birth of new concept
makes understanding the code easier. (If you had started browsing
jhalfs-2.0 code without having been part of its evolution you would find
it very difficult to understand or modify.)
> jhalfs born as a POC about automatizing the build from the book sources
> instead from manually created XML profiles (like nALFS was doing) to
> demonstrate that such thing was possible. Due the lack of available
> programmers to implement it in compilable code, the bash form has been
> extended and enchanced until what it is now, and what could be in the future.
> But I think the bash-based code will lack allways of a crucial feature: the
> ability to control simultaneouslly several remote installations/updates.
jhalfs-2.0 serves its purpose well, to automate the extraction and
building of LFS series book. It is possible to move beyond this
definition but not without pain.
> Said that, maybe you could put your hands on the development of that new alfs
> tool based on your ideas and your own way to do the things, helpped by other
> programmers if there is someone interested.
> I will be very happy in someday we have a alfs binary implementation that make
> obsolete the bash-based jhalfs code.
jhalfs-3.0 will have another definition and code will be written to
support those specs. Specs first, code later.
More information about the alfs-discuss