cvs commit: ALFS syntax.txt

Lee Saferite dsaferite at yahoo.co.uk
Sat Apr 6 10:50:55 PST 2002


Sorry if this email is ugly, I'm using my webmail to
reply.

I have to say I disagreed COMPLETLY with the idea of
multiple <base> tags.  It's a VERY badf idea, From my
POV.  the base is either specified or not, but having
multiple <base> elements leave it open to bad
mistakes.  Plus, if you have a <base> in your
container element, should it be added to any local
<base> or should any local <base> over-ride the parent
one.  I'm babbling.  I just DON'T like that idea.  As
for the <option> tag, well you are already doing some
processing on it, you build the line to pass on to the
external program.  why not do a simple check to see if
the option matches one the handler can do internally? 
I can't imagine this would change much.  The handlers
that don't care about local options could choose NOT
to process this, the ones that have local options
could look for things it knows, and if it doesn't have
an external program, it could discard/error all the
extra crap it finds.  I could also live with base as
an attribute.  Although, I prefer elements.  if you
get too complicated on the attributes, then the
element tag looks like utter crap, or is too
complicated to read.  I mena, you should just be able
to see <mkdir> and know that every element under it
pertains the makeing a dir.  but when you put
attributes into an element, then it makes it into a
visually different thing.  my $0.02

Lee 


--- Neven Has <haski at sezampro.yu> wrote: > On Thu, Apr
04, 2002 at 11:05:43PM +0200, Lee
> Saferite wrote:
> > > The only tags that an implementation should just
> append is <execute>,
> > > <make> and <configure>.  Those are the _only_
> tags, afiak.  So, do we
> > > make an exeception in this regard?  Or just use
> <parameter>?
> > > 
> > > Id prefer to just use <option> and make sure we
> are clear on it's
> > > proper usage then mixing up <parameter> and
> <option>.  I just really
> > > like<option> over <parameter>, that's all.
> > > 
> > > Dunno.. hopefully you will all reply agreeing
> with me and making my
> > > simple... [ya right! ;)]
> > 
> > I'll say this.  The parser (nALFS, etc) should be
> intelligent enought to
> > strip out parser 'options' and pass on the rest. 
> I mean, once the
> > syntax is decided upon, there will be specific
> options that the parser
> > should recognize and possible implement.  Once
> those are removed, in the
> > case of make, execute, and configure, then you
> would pass on the rest of
> > the options verbatim.
> 
> I don't think there is a need for such approach. If
> we start using a
> single element, there will be elements that will use
> it to _only_ append
> its content to the command (configure, make) and
> elements that will _only_
> recognize specific options (mkdir, copy). So there
> actually won't be
> cases (at least there isn't any for now), mixing the
> two (main reason
> I think we should have two different elements, BTW),
> so no need for
> parsing_and_striping, again - at least for now.
> 
> But I don't think that's the point here. I see this
> as a syntax issue
> only, to make a difference between two, IMHO,
> different things.
> 
> > Well, you could try
> > 
> > <mkdir>
> >    <base>/mnt/lfs</base>
> >    <name>bin</name>
> >    <name>sbin</name>
> >    <name>usr</name>
> >    <name>usr/local/games</name>
> >    <option>parents</option>
> > </mkdir>
> 
> Although there are much more typing involved here, I
> think I like
> having the element per directory like this.
> 
> > > > So I would vote for leaving the _structure_
> the way it is now, and
> > > > only rename the elements. <name> (as suggested
> elsewhere) might be a
> > > > good idea. <root> or <dir> instead of <base>
> are options too.
> > > 
> > > <mkdir>
> > >     <base />
> > >     <target|name />
> > >     <option />
> > > </mkdir>
> > 
> > 
> > I would think <root> might get confused with
> changinf the root ala
> > chroot.  and <dir>... dunno, doesn't seem right. 
> <base> is different,
> > but I cant think of a better one either.  I would
> think it says the
> > 'base' of the filename/dirname is BLAH and the
> 'name' of the file/dir is
> > BLAH.
> 
> If we choose to have more attributes, "base" could
> be one of them
> (which Jesse proposed for <make>, for example). That
> would give us:
> 
> <mkdir base="&LFS;/usr">
>     <option>parents</option>
> 
>     <name>bin</name>
>     <name>etc</name>
>     <name>include</name>
>     <name>lib</name>
>     <name>sbin</name>
>     <name>share</name>
>     <name>src</name>
> </mkdir>
> 
> I like having "base" as an attribute, but on the
> other hand, maybe
> we should allow multiple <base> directories too?
> Something like:
> 
> <mkdir>
>     <option>parents</option>
> 
>     <base>&LFS;/usr</base>
>     <base>&LFS;/usr/include</base>
> 
>     <name>bin</name>
>     <name>etc</name>
>     <name>include</name>
>     <name>lib</name>
>     <name>sbin</name>
>     <name>share</name>
>     <name>src</name>
> </mkdir>
> 
> Although this looks huge. :)
> 
> 
> Neven
> 
> -- 
> Unsubscribe: send email to
> listar at linuxfromscratch.org
> and put 'unsubscribe alfs-discuss' in the subject
> header of the message
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
-- 
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