From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-22 02:34:21
> > So, you wanted to specify some feature for your library which the user
> > can override? Why should it be in usage-requirements?
> Well... what is the right way to do it? The library has a header that does
> different thing depending on the value of the feature. So in order to use
> the library I need the feature to be set. Isn't that what
> usage-requirements are for? Only now I do not want a specific value of the
> feature - just that it is set with any of the 4 possible values. Then when
> I try to use the library it implies that the feature must be set also for
> the exe. If it is not, then a default value is used (supplied by the
> library usage-requirements?). If it already is, then this value is used for
> selecting which version of the library the exe requests. I've found no way
> how to do it.
I believe usage-requirements are not good here. They specify that dependent
target *must* be built with specific property, and you've tried to use to the
specify that dependent target must be build with *some* value of a property.
If I understand correctly, the approach you've arrived at is to make feature
non-optional, and the drawback is that now all targets are built in four
variants? In other words, it's good to have features specific to a main
feature mode : 1 2 3 4
: link-incompatible ignored-unless-explicitly-made-relevant ;
lib test : test.cpp : <explicitly-relevant-feature>mode
: : <explicit-relevant-feature>mode ;
exe app : app.cpp test ;
With this setup, 'mode' feature will only affect target which have explicitly
specified that they care about 'mode'. What do you think? (Note that this
just an idea, syntax details might be different).
> When I was linking to the library compiled with different value of the
> feature than was the one set on the exe. That was why I've set the feature
> to be link-incompatible in the first case. Just to prevent this from
> >>Great! Thanks. I just hope I am not being pain in t... I understand that
> >>bbv2 can use some more testing & bug reporting, right?
> > Sure! Testing and bug reporting is very important now and it's
> > interesting to see how V2 is used in many ways. Thanks for your
> > contributions!
> I'll keep hammering it to see if it can do what I want it to do and if it
> is as simple as I would want ;-)
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