al593181 at mail.mty.itesm.mx
Mon Jan 28 11:30:02 PST 2002
On Mon, Jan 28, 2002 at 09:49:29AM -0800, Jesse Tie-Ten-Quee wrote:
> On Sat, Jan 26, 2002 at 12:00:53AM -0600, Felipe Contreras wrote:
> > * Grouping
> > I think grouping is essential in order to control exactly where we
> > are, which commands are going to be executed, save the current
> > state, restore from where we left, etc. I think no scatered
> > commands should lay around, it's like seeing just a bunch of
> > commands in the lfs book witouth information belonging to which
> > chapter it is and which part of the chapter you'll not know if to
> > type those commands or not.
> Yes, i've never liked having some of the commands outside of a package,
> but there isn't really all that much we can do, unless we make a dummy
> package and put them inside it or move more of the config file generate
> into there correct affiliated packages.
You decide, we think about a way or we just leave it until it comes
itself. IMHO a <commands> or <setup> should do it, might be the name
should be changed.
> > 1. The xml profile is translated to bash, then executed.
> This i believe you are doing.
> > 2. The profile is translated to shell commands and each one of them
> > is piped to a coshell that executes them and return the status.
> This is how nALFS does it, i believe.
What about the third?
> > 4. Each command is handled directly by a system call or function.
> This is how id like to see things done.
> > Each one of them has it's pros and cons, and it all depend on the
> > language of the implementation. Probably the implementations will
> > have to use some sort of convination, since for example an
> > implementation of the 4th alone will not handle "./configure", ther
> > is no way to do that without system().
> Correct. Well system() is an evil system call and it's much nicer to
> use a PIPE imo.
True, pipes are much better.
> > There is more stuff, but I agree with Jesse, we should start with
> > something now. If these ideas are at least considered I'll be happy with
> > the path alfs will take.
> *blinks* He agrees him me!?! *blinks again* How long have i waited for
> this day.... :)
LOL, those long discussions need to lead to this, doesn't?
Anyway I'm sad this is not design/implementation but simple project
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