Re: Some thoughts on targets

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-09 09:03:34

Vladimir Prus <ghost_at_[hidden]> writes:

> 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

An abstract dependency node.

> and what are dependents supposed to do with it? 

Umm, depend on it?

> What is the type of that target?

Whatever you want it to be?

>> > 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"?

No, it means "percent", i.e. a fraction x 100.

>> 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 ;-)

I guess I like the double-slash thing a little better because it
sticks out a little more and still looks like path separation. We'd
need to be careful to handle the initial // on remote paths for some
OSes specially.

/boost/program_options$program_options

is probably a mistake because of the special role of '$' in Jam

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com