[C++-sig] win32: BOOST_PYTHON_MODULE always exports DLL symbols

David Abrahams dave at boost-consulting.com
Fri Jan 3 18:37:36 CET 2003


"Nicolas Lelong" <n_lelong at hotmail.com> writes:

>> Wouldn't it be enough to have a symbol which determines whether module
>> init functions are exported or not, in addition to having
>> BOOST_PYTHON_STATIC_LIB?
>
> Sure, that should be enough, but I was wondering if there would
> exist any other specificities tied to extending an embedded
> Python.  Ican't think of any other - but this could be 'smart' to tie
> all of them to a single symbol.  Moreover, I can't see any other use
> of not exporting module init functions besides extending an embedded
> python.

My problems with BOOST_PYTHON_EXTEND_EMBEDDED are twofold.  First, it
feels like premature generalization to me.  Second, it ties orthogonal
concepts together (extending and embedding).  Can't you extend an
embedded Python by sticking a dynamically-linked extension module in
the PYTHONPATH?  I also don't want to make this symbol define
BOOST_PYTHON_STATIC_LIB, since you could still use an embedded Python
with a Boost.Python DLL.

It seems to me that BOOST_PYTHON_STATIC_MODULE is the right symbol for
controlling what you want.

Am I missing something?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution





More information about the Cplusplus-sig mailing list