cvs commit: ALFS syntax.txt

Mark Ellis mark.uzumati at virgin.net
Fri Mar 29 02:50:13 PST 2002


On 2002.03.28 11:09 Neven Has wrote:
> On Wed, Mar 27, 2002 at 09:55:35PM +0000, Mark Ellis wrote:
> > > <remove />
> > >
> > > No subtags or elements are needed.  I think we can all agree on
> this
> > > ;)
> >
> > Oh i dont know, looks like a good place for a <base> :) Actually now
> i
> > think about it it does ! How about :-
> >
> > <remove>
> >    <base />
> >    <cant think of a name for this bit />
> > </remove>
> 
> I don't remember anyone ever explaining why this is the only element
> without <base> or any other sub-element. I don't know if this is the
> exact reason (if any existed at all), but I think it would be better
> to
> stay with the way it is now because it's much less error prone. It's
> harder to make mistakes (and wipe your disk clean) when you have to
> type
> the full path of the file you want to delete.
> 
> Also, I would like very much that we add <option>recursive</option>
> here
> and set default to just a simple rm(1)-like operation.
> 
> That would make screwing things up even harder.
> 

Sounds ok, so how about

<unpack>
   <name />
   <option />
</unpack>

I added the <name> 'cos i don't like the idea of mixed content in an 
element unless it's absolutely necessary.

> > > Similar to unpack.  However if we use <option /> with configure
> and
> > > make
> > > (and other tags), the usage of <options /> may seem confusing.  It
> may
> > > perhaps make more sense to just use <option /> also, while
> allowing
> > > multiple tags. (so if you need say resursive and resursive, you
> have
> > > two options, one for each)
> > >
> >
> > Stick with param for the others, see above. Multiple tags for
> multiple
> > options, sounds reasonable.
> 
> Yeah, I like very much multiple <option>s here.
> 
> > > <mkdir />
> > >
> > > <mkdir>
> > >     <base />
> > >     <dir />
> > > </mkdir>
> > >
> > > Will talk more about this when i get around to the base/dir issue.
> >
> > Got an <options> in there too, to create parent dirs if necessary.
> 
> <option> ! ;)
> 
> I can't think of the reason we used <options>foo bar</options> in
> a first place. :)
> 

Oops, i guess the singular would make more sense if we go for multiple 
<option>s :)

> > > <setenv>
> > >     <variable />
> > >     <value />
> > > </setenv>
> > >
> > > I'm presently using this too, which was taken from nALFS.
> >
> > Dunno exactly what Neven is doing with this, but i treat an empty
> > <value> as setting the var to a null, and no <value> element as
> > unsetting the var.
> 
> Could someone clue me by explaining me the difference?
> I'm unsetting the variable (unsetenv(2)) in both cases.
> 

Hmm, good question. When i implemented the new syntax something made me 
thing this was the thing to do, but i cant remember what in particular. 
It must have been a script/makefile somewhere that distinguished 
between an empty variable and a nonexistent one, but it's entirely 
possible i imagined the whole thing :)

> > Assuming <base> refers to the directory from which all ops are
> 'based',
> > the only common usage of <dir> i'm familiar with is in <mkdir> yes ?
> In
> > which case, rename that <dir> as <name>, or even <target>, though
> i'd
> > prefer <name>, you're making a dir so <name> shouldn't be ambiguous.
> 
> <name> is nice.
> 
> > Stuff i've got that you havent, for whatever reason.
> >
> > <chroot dir="...">
> > </chroot>
> >
> > This one also came into the generic container thread.
> >
> >
> > <patch>
> >    <base />
> >    <param />
> > </patch>
> >
> > Always considered patch a bit odd, 'cos without an "optional" param
> its
> > useless. Maybe needs a rethink.
> 
> Hm, the same argument as for <configure>, someone brought up. I can't
> make
> up my mind whether to just use <execute>, with <command> being the
> thing
> that distinguish them, or not.
> 

<configure> is fine with just <base>, params aren't necessary.

> I believe we could think about what elements can be implemented
> without
> calling the external program. All those that can not, could be just
> <execute>.
> 
> There is something to be said about having distinguishable elements
> for
> different actions, but in the end, it's still system command needed to
> be
> <execute>d.
> 
> But on the other hand this might be a bit extreme, since <make> also
> belongs in this category. And we all kinda grow to it. :)
> 

Make, configure unpack and patch would i believe be completely 
impractical to implement without the external programs, notice i didn't 
say impossible but you'd have to be crazy to do it :) The others are 
all doable, in fact off the top of my head i think the only one i dont 
use perl calls (and hence library calls) for is remove, which is no 
biggie.

make and configure i like as named tags, they're too big a part of the 
process. patch i could probably keep or drop.

> > <search_replace>
> >    <base />
> >    <file />
> >    <find />
> >    <replace />
> > </search_replace>
> >
> > Invaluable to all but the previously mentioned sed gurus :)
> >
> > <textdump mode="append | overwrite">
> >    <base />
> >    <file />
> >    <content />
> > </textdump>
> >
> > Default is overwrite.
> >
> >
> > Those last two in particular will probably start the <execute> vs
> > specific elements thing again :) Depends what you're trying to
> achieve,
> > either encapsulating shell commands in an automated build system or
> > creating a build system with its own syntax. Both equally valid
> goals,
> > personally i like specific elements.
> 
> Why these last two? I think they clearly belong in "having a separate
> element" category. We don't need to use a system command to implement
> them.
> 

Umm, cant think why i said that, my mind must be going :)

Mark
-- 
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