[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