From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-07-06 09:56:16
On Wednesday 06 July 2005 00:38, Valentin Samko wrote:
> I am trying to adapt bbv2 to use it instead of existing build system
> for a large project, and one of the requirements is to be able to have
> several libraries/projects with the same name, but different version
> I am happy to add new bjam rules for these requirements, but I am not
> sure I understand how to write these rules. I found <version> feature
> and corresponding rules in \v2\build\modifiers.jam with a small example
> in \v2\example\versioned\jamfile.jam. What exactly does this future do,
> and how can it be used? Does it let user have several projects with
> the same name, but different version numbers (or at least several libraries
> with the same name)?
I think that feature was meant to add version suffix to target names, but as
is mentioned in another post, it's not really used at the moment.
> Also, is it possible to write a rule/feature which will modify the list of
> all the dependencies of the current executable? How?
> For example, I have executable "A" which uses library "L1", and "L1" uses
> library "L2.v1.01", and I would like executable "A" (by adding a
> rule/feature/...) to link to "L2.v1.02" instead of "L2.v1.01"
> (without recompiling "L1", which uses "L2.v1.01").
> I can guarantee binary interface compatability between "L2.v1.01" and
> In other words, I would like to be able to use L2.v1.01 in my
> executable "A" without recompiling "L1", which was compiled against
I'm probably missing something. What about:
lib L2.v1.01 : source1.cpp ;
lib L2.v2.01 : source2.cpp ;
lib L1.v1.01 : source3.cpp L2.v1.01 ;
exe A : L1.v1.01 L2.v2.01 ;
I'm not really what what this will accomplish, and why you would link to two
versions of the same library, but that's what you've asked for ;-)
I suspect you need something more, if so, can you clarify?
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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