Re: [jamboost] Re: propagation of usage-requirements

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-12-17 09:26:41

Hi,

Em 17 Dec 2004, às 08:54, Toon Knapen escreveu:

>
> David Abrahams wrote:
>
>>
>> Of course I agree with everything you have said. I am only arguing 
>> that
>> the author of B should be able to be explicit about which of A's
>> usage-requirements are propogated on to B's clients.
>>
>
> Is there a use-case for this? I can't think of a usage-requirement that
> I do _not_ want to propagate to direct but also indirect dependents.
> Could you give an explicit example?

Sorry for joining this thread so late, but I think I may have a problem 
with this on Windows.

I have many projects that boil down to this:

// A.h
#if defined (A_IS_LIB)
# define A_API
#else
# if defined (A_EXPORTS)
# define A_API __declspec (dllexport)
# else
# define A_API __declspec (dllimport)
# endif
#endif

// B.h
// Similar to A.h

# Jamfile
lib A : A.cpp : <link>shared:<define>A_EXPORTS 
<link>static:<define>A_IS_LIB : : <link>static:<define>A_IS_LIB ;
lib B : B.cpp A/<link>static : <link>shared:<define>B_EXPORTS 
<link>static:<define>B_IS_LIB : : <link>static:<define>B_IS_LIB ;

exe C : C.cpp A B ;

Basically:
- B uses A statically, so A is used with the A_IS_LIB macro defined.
- C uses A dynamically, so should NOT have A_IS_LIB defined BUT gets it 
from second-hand usage-dependencies.

I haven't tried it but I'm pretty sure I'll be hit by this sooner than 
later.
I know the example seems odd but, when you have products composed of 
over 30 modules, it does happen.

Regards,

Pedro