Re: Some thoughts on targets

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

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > Use case 1. Suppose my program_options library is accepted to Boost,
>> > and I'm pressed to implement both library version and all-inline version.
>> > Someone might want to write
>> >
>> > exe hello : hello.cpp @/boost/program_options%program_options ;
>> >
>> > Ordinary, a library target will be created, and usage requirements (like
>> > <include>/path/to/boost) will be applied. When user wants all-inline
>> > version (using some feature, for example), he'd get no real target to
>> > consume, but still, the usage requirements must be applied.
>>
>> 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.

> 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 "%" ;-) I can't
come up with any strong arguments about this. One other idea might be
to use "//", but it's just an idea.

>> > Use case 2.
>> >
>> > exe hello : hello.cpp platform_sources ;
>> > alias platform_sources : win.cpp : <os>NT ;
>> > alias platform_sources ;
>> >
>> > Now, on any OS except for NT, the "platform_sources" main target will
>> > generate no files. I think this should be allowed.
>>
>> Sure.
>
> OK, good that we've agreed. A test for this use case is in CVS for a
> couple of days already, and even works.

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