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.
> 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
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