cvs commit: ALFS syntax.txt

Neven Has haski at sezampro.yu
Sat Apr 6 06:46:23 PST 2002


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



More information about the alfs-discuss mailing list