Re: [jamboost] Re: link-compatibility poll: results and feature removal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-22 02:34:21

Hi Zbynek,

> > 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 
target?

For example:

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

Ok, understood. 

> >>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 ;-)

Great.

- Volodya