Greetings and a General Cleanup

George Boudreau georgeb at linuxfromscratch.org
Fri Nov 3 14:10:38 PST 2006


M.Canales.es wrote:
> 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 mailing list