Re: [jamboost] Re: Some thoughts on targets

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-09 07:14:11

David Abrahams wrote:

> >> Those sound to me like two different subvariants of the same main
> >> target. Just as you can ask for the library with inlining off you
> >> might also request the library completely in headers. Is that
> >> pushing the notion of "library target" too far?
> >
> > No, I've had just the same in mind. But note: for in-headers
> > implementation, the library main target will create no virtual-targets.
>
> That doesn't seem to be a foregone conclusion. We could generate a
> NOTFILE target for the library.

We could, though I don't like this approach. The model where call to 
'generate' returns virtual target that correspond to creating targets is 
simple. The model where you get NOTFILE target is a bit vague --- what does 
that target corresponds to and what are dependents supposed to do with it? 
What is the type of that target?

> > But usage requirements still must be propagated. So, actually,
> > propagation of usage requirements is orthogonal to creating targets
> > -- and I've made a change to that effect recently.
> >
> >> Also, I may have missed something, but is there a reason we need two
> >> tweaky symbols to specify remote main targets? Can't a syntax like
> >> /boost/program_options_at_program_options do that job?
> >
> > The discussion we had with Ali converted to the same point: we'd use
> > a single symbol, which will separate project and target. So far, I'd
> > like this symbol to be '%'. In particular, this will make transition
> > to new target-id syntax more smooth.
>
> Being American, of course, I'd prefer to use "$" than "%" ;-) 

Does "%" mean "cent"?

> I can't
> come up with any strong arguments about this. One other idea might be
> to use "//", but it's just an idea.

Comparing

/boost/program_options%program_options

with 

/boost/program_options//program_options

I cannot say that I prefer anything strongly. Maybe, we should toss a coin ;-)

- Volodya