Re: Various issues

On Sat, 9 Aug 2003, Bram Moolenaar wrote:

> > * :do something $source { filetype=h } sets the source name to
> > $source{filetype=h} - not what you would expect. And sufreplace() on such
> > a broken filename leaves the trailing } in place.
>
> Well, if you give attributes to the source file(s), they end up in the
> value of $source.  That's what you specified.  You can use $-source to
> get rid of the attributes.  An alternative would be to remove the
> attribute from $source and put it on the node, but you probably wanted
> this filetype to be used only when invoking the action, not as _the_
> filetype for this source.

An example where $-source isn't trivial to realize is in Python code - the
archetypical `sufreplace("",".h",source)`, say. I'm working around it now
with tsrc=$-source and then using tsrc instead in my Python snippets.

> That a trailing } is left behind is a bug in sufreplace().  Another bug
> in that function in a short time.  I think I'll have to change it into
> something more clever than just using a string replacement on the whole
> argument.

I've coded up a replacement of sorts, that has the side effect that in the
sufreplaced list all the attributes are gone. It's on another machine
though, I'll send it in on the weekend.

> > 	- adding support for dir supportin :child so you can say :child
> > dirname and have AAP read that as :child dirname/main.aap
>
> I suppose you see this as a way to specify sub-projects by the name of
> the directory.  Is leaving out "/main.aap" enough advantage to add code
> for this and let the casual user guess that "/main.aap" is automatically
> appended?

Ideally the same support would be added to :execute . After all, when
running AAP if you don't mention the recipe name it looks for main.aap.
That suggests to me that whenever you go about specifying another recipe,
if there's no explicitly mentioned recipe, then it should look for
main.aap (there) instead.


> > 	- adding support for multiple children, so you can say :child dir1
> > dir2 dir3
>
> Why not use separate commands?

It's something of an automake holdover. :child $SUBDIRS seems much more
convenient that "for i in var2list(SUBDIRS): :child $i". Maybe it never
happens.


A lot of this stuff is convenient for my automake wedge - a few aap
patches and some recipes that make transitioning an automake+based
application to AAP as simple as

:include am.aap

it works fairly well on KDE's Makefile.am's, except where exotic AM stuff
like conditionals and includes comes in.


-- 
 Adriaan de Groot    adridg-FlD2LfDziEhmR6Xm/[email protected]     Kamer A6020     024-3652272
GPG Key Fingerprint 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE
               http://www.cs.kun.nl/~adridg/research/




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01