An experimental design for (x)alfs

pak_lfs at freemail.gr pak_lfs at freemail.gr
Fri Nov 25 05:54:12 PST 2005


Jeremy Huntwork wrote:
> Some practical examples might help some of us grasp all your concepts
> more quickly. Perhaps you can describe in detail too what you mean by
> Stages and Jobs?

Subhash Chandra wrote:
>I didn't completely get your ideas but, isn't what you are asking
>simply something like wrapups for larger chunks of scripts than
>individual commands?

>I understand that creating profiles in current xml are a pain.

>How ever isn't it possible to make xml files with default config (the
>./configure --prefix=/usr && make && make install) and include that
>file into individual package files thus creating your one line
>profiles? And when the scripts vary from such defaults, You would
>obviously need smaller units of commands to use as you please.

First of all, let me bring up the two basic use cases for alfs and argue
about current ALFS problems with these. 

The first case is the commands being parsed directly from the book, ala
jhalfs. Does everybody here agree that it is very difficult and unlikely for
us to find the resources to implement a "code transformation engine"
that will be able to parse all of bash and the command-line syntax of
all unix tools and produce the low-level XML that ALFS wants as input?

Does everybody also agree that this will be still the case even if we
improve the ALFS "specification" (beyond the DTD), for example
to allow regular expressions in <search_replace>?

The second case is building your own profiles. In this case it is IMO
*vital* to provide some *libraries* of common "profile code",
or maintainance quickly becomes a nightmare. E.g., I think KDE 4
will move from autotools to an scons-based build system.

With ALFS, this means you have to rewrite *all* KDE-related profiles
of yours even though for autotools you just do ./configure and with
the new system you will again do it in a standard way.

Wouldn't it be nicer if one could just do 
s/std_autotools_prepare/std_scons_prepare in all related packages?

About using xincludes to provide this *library* functionality:
The problem with xincludes is that I don't believe they can be *configured*
in any way:

E.g., say you have a standard profile snippet that does
<configure>
    <param>--prefix=/usr</param>
</configure> 

say now that you have a package that needs ./configure --prefix=/usr 
--enable-shared. Idealy you should be able to declare only the *differences*
from the standard as arguments to the library function. How can this be
done with xincludes except by resorting to hacks like the following?

&std_configure_begin
differences ...
&std_configure_end

So, it seems the only reasonable XML solution to the "library" problem is
the way Java's Ant build tool does it, i.e., create a new *tag* for each
function you want and write handler code for it (in C/whatever language
the tool is written in) to actually provide the functionality. For Ant this 
works well as its target audience is Java developers who prefer to write
Java classes for build jobs rather than shell scripts,I doubt that this is the
case for most of LFSers though, no?

OK, I 'd like to first hear your opinions on these and if we agree
we can move on to discuss if/how palfs can solve the above problems.

To summarize, my main point is that neither XML nor any other declarative
language for that purpose, can efficiently be used for alfs in either
the system-command level (like current ALFS) or in the library command level
(like Ant). The declarative part which is the core of alfs engine, must be 
even higher than these levels of abstraction, whether it is implemented in 
XML or not.


Thanks,
Pantelis



____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.



More information about the alfs-discuss mailing list