cvs commit: ALFS syntax.txt
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
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
If we choose to have more attributes, "base" could be one of them
(which Jesse proposed for <make>, for example). That would give us:
I like having "base" as an attribute, but on the other hand, maybe
we should allow multiple <base> directories too? Something like:
Although this looks huge. :)
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