From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-09 00:42:25
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. 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
> > 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.
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