Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-27 08:15:01

On Friday 24 June 2005 18:01, hf_pabst wrote:

> Export/import symbols into/from a DLL without the need of a top-level
> header.
> Such a typical header is now (logically) moved into the build system.
> Exporting becomes naturally a 'requirement' and importing will be
> an 'usage-requirement'.
> In case of more than one component (dll) per main-projects with inter-
> dependencies, that mean importing and exporting symbols for a single
> component at the same time, you can't have a simple control header
> that says 'dllexport' or(!) 'dllimport'. It's needed to tag each
> component with an own (unique) symbol. Now you have
> dllexport/dllimport per component (symbol).

I don't quite understand this. When building sources for each given DLL,
symbols from that DLL are marked as exported, symbols from other DLLs are
marked as imported. Can you detail the scenario you have.

> This 'dll.lib' rule provides the standard to use the target name
> (uppercase) as symbol for the preprocessor and define it
> automatically with dllexport, dllimport or nothing (link static). The
> target name should always unique per component. Everything that needs
> to be exported/imported is named (tagged) naturally with the
> component name, i.e: class LIBMYCOMPONENT my_type { ... };

Ah.. so you're making the 'lib' rule automatically define a preprocessor
symbol corresponding to the name of the built library? I agree that for
Windows, that behaviour is always needed, and so nice to have.

> ---- jam code ---
> rule lib ( names + : sources * : requirements * : default-build * :
> usage-requirements * : symbol ? )
> {
> echo $(names)": using extended version of 'lib' rule" ;
> if ! $(symbol)
> {
> # By default use the uppercase name
> symbol = $(names:U) ;
> }
> import os ;
> if [ os.on-windows ]
> {
> requirements +=
> <link>shared:<define>$(symbol)=__declspec(dllexport)
> <link>static:<define>$(symbol)="" ;
> usage-requirements +=
> <link>shared:<define>$(symbol)=__declspec(dllimport)
> <link>static:<define>$(symbol)="" ;

I am not sure this is the right approach. When the library is used in a
project *not* build by Boost.Build, then nothing will be defined by the user,
and nothing will be exported.

How about defining $(symbol)_SOURCE macro, and checking for that macro in
sources like this:

#define WHATEVERDECL __declspec(dllexport)
#define WHATEVERDECL __declspec(dllimport)

class WHATEVERDECL my_class {};

I tough the above approach is pretty standard, though I'm not a Windows

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at