From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-12-17 09:26:41
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
>> 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:
#if defined (A_IS_LIB)
# define A_API
# if defined (A_EXPORTS)
# define A_API __declspec (dllexport)
# define A_API __declspec (dllimport)
// Similar to A.h
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 ;
- 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
I know the example seems odd but, when you have products composed of
over 30 modules, it does happen.
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