A bad thing about ALFS in c

Neven Has haski at sezampro.yu
Thu Nov 8 08:23:57 PST 2001

On Wed, Nov 07, 2001 at 10:08:09PM -0600, Felipe Contreras wrote:
> On Wed, Nov 07, 2001 at 10:47:40PM +0100, Neven Has wrote:
> > We really shouldn't be thinking in anything, but XML. :)
> > 
> > The whole idea is (or at least it was) language independence.
> > 
> > So, we should think about how to represent something like
> > "export tmp=${LFS%/*}" in XML and not how to implement it in C. That is
> > something that should be left to backend writers.
> > 
> > ALFS is not in C, only its implementations could be written in it.
> > Maybe we could say that ALFS is in XML, if we look at the profiles.
> Language independence of the shell commands or the backend to
> interpreter?

Language independence of the backend. So that, for example, creating of
directories can be done with mkdir(3) (through a shell), or fully implemented
in the handler (some "stripped down" mkdir(3) using mkdir(2) if backend is
in C) or, if backend is written in Perl his mkdir() etc.

Well, at least that _was_ the idea. :)

I know that reinventing mkdir(3) (nor using it _through_ C or some other
language) doesn't make much sense. One of the advantages of rewriting it in C
might be speed, but the difference (calling external command or not) would be
really silly. The other advantage that comes to mind could be independence
from the shell itself. But that's also pretty impossible since there are
things like patch, configure etc. for which one would have to do exec(2)
directly and again - act as a shell in a way. For example.

> Let's supose I run a program called "special_ugly_config" that export
> some environmental variables and then you run program "ugly_installer",
> if you do that with different system() calls the environment will be
> lost since the shells are different.

Yes, although that would really be special and ugly as you say, we have to
be prepared for something like that as well. And yes, it's not an easy task
to "grab" the changed (by some system command) environment.

> I also think that there is no need to find a way to implement "export
> tmp=${LFS%/*}" in XML, that's just too much to think if the ones that
> write sources expect things to be written on the shell.
> So ALFS is in XML, but the XML data in which format will be? it needs to
> have some kind of shell commands, doesn't it?

Well, the original idea is no. Everything would be split into different
elements (<mkdir>, <link>, <copy> etc.) and only some weird and
not_worth_adding_a_new_element_because_of_it things would be in <execute>
as shell commands. The way it is now, actually.

But then we come to that really really weird stuff which isn't easy to execute
through something like C (by calling a shell), for the reasons above, nor
represented in XML.

So now what? Should be dump the "backend language independence"?

I could agree with that, but before (and if) we do it, we should really first
create a nice protocol for frontend<->backend communication.

That way, backend could be extremely simple bash script - it could just
receive (already parsed by frontend) commands, execute them and report the
exit status for each one. Something similar to your sourcer, but where
xmlparse would actually be a daemon receiving the commands from the frontend
(and not parsing XML profiles on its own).

Well, just one of the solutions... :)


Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list