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.
> 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
is probably a mistake because of the special role of '$' in Jam
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk