[Boost-users] [preprocessor] usage problem

From: Christopher Lux (christopherlux_at_[hidden])
Date: 2007-06-07 03:09:23

hi,
i want to do the following in a win32 project, which generates a dlls. commonly there is a macro defined like this:

#ifdef DLL_BUILD
#define __scm_export __declspec(dllexport)
#else
#define __scm_export __declspec(dllimport)
#endif

now i have several projects which generate dlls and depend on each other like:

core_lib <- graphics_lib

now to do this it is needed to differenciate between dll builds. lets say with a macro CORE_DLL_BUILD and GFX_DLL_BUILD.

BUT i think this is hell ;) and thought of something like this:
i would like to have one macro __scm_export(lib) which decides by the lib parameter which lib is build. i tried it the following way:

(code broken out of context)
#include <boost/preprocessor.hpp>
#include <boost/preprocessor/detail/is_nullary.hpp>

#if SCM_COMPILER == SCM_COMPILER_MSVC
     #define __scm_export(lib) export_(BOOST_PP_EXPAND(BOOST_PP_CAT(SCM_BUILD_LIBRARY_, lib)))
     #define export_(lib) BOOST_PP_IF(BOOST_PP_IS_NULLARY(lib), __declspec(dllexport), __declspec(dllimport))
     #define __scm_private(lib)
#else
     #pragma error "unsupported compiler"
#endif

this way i only have to define something like /DSCM_BUILD_LIBRARY_core=() for the core project and /DSCM_BUILD_LIBRARY_ogl=() for the graphics library and use __scm_export(ogl) and __scm_export(core) in the particular libraries.

this works perfectly, BUT i am searching for a more elegant way to do this, because i do not like the definition of a unary macro for the projects. i would like more to define it this way:

/DSCM_BUILD_LIBRARY=core and /DSCM_BUILD_LIBRARY=ogl for the libs. i experimented with BOOST_PP_IIF and so on, but the problem is if these macros are presented with an undefined macro (like when i use the one lib in the other) they do not use the false alternative and insert a lengthy macro. after a long night i came up with the BOOST_PP_IS_NULLARY workaround, but as is said i do not think is is a very good solution.

dies anyone have suggestions how to solve this on a more elegant way?

Thanks
-chris
-- 
Christopher Lux |
                 | Bauhaus University Weimar
                 | Faculty of Media - Virtual Reality Systems Group