Re: [jamboost] Header scanning change

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-20 06:36:06

Hi Mark,

Mark Sheppard wrote:
> > First, I believe that V2 already handles "" includes. In
> > fact, I believe V1 handles them as well, since I've added
> > that code to it a long time ago.
>
> So it does. I hadn't looked at V2 (or even V1) before, only
> the Perforce Jambase.

Okay.

> > Second, your change is very interesting. For example, to find
> > out the location of the scanned target, V2 has to store
> > binding and later retrive it. I though about adding "BINDING"
> > variable, which will be automatically set. Passing boundname
> > as 'target' is an interesting idea.
> >
> > But there's a problem, though. V2, V2 and Perforce Jambase
> > use grist on header targets to distinguish between different
> > scans of the same file. And with your change, grist is no
> > longer available in scanner. I'm not sure how to handle this.
>
> Yes, I ran into this problem after using my change. The way
> I've fixed it is to pass both the name and the boundname to
> $(HDRRULE):
>
>
> --- jam_src.orig/headers.c 2002-05-28 21:35:12.000000000 +0100
> +++ jam_src/headers.c 2003-10-20 11:43:08.000000000 +0100
> @@ -87,13 +87,14 @@
> FRAME frame[1];
> frame_init( frame );
> lol_add( frame->args, list_new( L0, t->name ) );
> + lol_add( frame->args, list_new( L0, t->boundname ) );

[...]

> Obviously this breaks backwards compatibility so isn't something you'd want
> to do in the mainline Boost Jam. Alternatives I thought of would be adding
> a BOUND_NAME builtin or a variable modifier (e.g. $(source:Z),
> unfortunately B is taken) which would return nothing before a target is
> bound.

This approach did not occured to me. Since header rule is called one for each 
scanned target, I think it's possible to pass binding to it. We'd only have 
to change prototypes of some rules, and it will be sufficient.

I'm not sure if it's necessary right now, but the change seems attractive.

- Volodya