FreeLists / openbeos / [openbeos] Re: need help with jam

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2004-06-04 at 11:54:02 [+0200], Jérome DUVAL wrote:
> >
> > In principle it looks quite OK. As Andrew already wrote, it would be
> > helpful, if you gave a bit more info what exactly your problem is.
> 
> As i wrote to Andrew, it seems adding a 'final' target makes jam build with
> the rules ...

I'm not sure, if I understand what you mean by that.

> > > Do i need to grist kill.c and kill.def somewhere ? How to do this btw ?
> >
> > Given the comment in your rule, you need apparently to grist the
> > parameters. :-P
> >
> > Grist is used to make create globally unique target identifiers. Most
> rules
> > that come with jam (like Main) automatically add grist to source file
> > names. So, if in your example you feed `kill.c' to such a rule, it will
> > actually try to find something like `<src!...>kill.c', while, as you use
> it
> > now,  MkBuiltinsComp generates `kill.c'. Hence there's a good chance that
> > things won't work properly. You either have to add grist to the parameter
> > you pass to the rule MkBuiltinsComp or you let the rule itself add the
> > grist, which make the invocations look less ugly. The second parameter
> > doesn't necessarily need grist, but it doesn't harm to add it. The rule
> > would thus read:
> >
> > rule MkBuiltinsComp
> > {
> > # MkBuiltinsComp <c file> : <def file> ;
> > #
> > # The rule adds grist to <c file> and <def file>.
> > #
> > local cFile = [ FGristFiles $(1) ] ;
> > local defFile = [ FGristFiles $(2) ] ;
> >
> > SetupObjectsDir ;
> > SEARCH on $(defFile) += $(SEARCH_SOURCE) ;
> > MakeLocate $(cFile) : $(LOCATE_SOURCE) ;
> > Depends $(cFile) : $(defFile) mkbuiltins ;
> > LocalClean clean : $(cFile) ;
> > MkBuiltinsComp1 $(cFile) : mkbuiltins $(defFile) ;
> > }
> 
> I now use UserObject rule to have my own extension built.

Please don't. AFAIK `.def' isn't a common extension, so UserObject is not 
the right place.

> It seems to work better.

There shouldn't be that many differences. Probably the only one is that you 
use a higher level rule now, which automatically adds grist.

> The big problem i have now is 'mkbuiltins' only
> outputs in the current directory (which can be anything in current
> current/src ... ).
> I didn't find how to go around this (changing current directory makes tool
> and targets paths wrong).
> 
> I think I should modify 'mkbuiltins' to have it output somewhere else.

That's probably the most sensible way. But you can also have a look at the 
RelSymlink rule and how it constructs a relative path between two 
directories using SplitPath and FRelPath. Or check out how e.g. the Yacc 
rule is implemented in Jambase (by moving the generated file to the right 
place).

CU, Ingo