[boost] [python] bogus backward-compatibility code

Subject: [boost] [python] bogus backward-compatibility code
From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2008-12-26 10:45:15

Hi!

I'm looking at versions up to at least 1.37, and in python/detail/config.hpp, 
I find found some code that is currently in my way, because I'm not sure what 
it should do. I'm talking about the following few lines:

 // backwards compatibility:
 #ifdef BOOST_PYTHON_STATIC_LIB
 #  define BOOST_PYTHON_STATIC_LINK
 # elif !defined(BOOST_PYTHON_DYNAMIC_LIB)
 #  define BOOST_PYTHON_DYNAMIC_LIB
 #endif

Notes here:
1. The first macro, BOOST_PYTHON_STATIC_LIB, is undocumented and probably (I'm 
guessing) an old spelling of BOOST_PYTHON_STATIC_LINK. It is used in some 
Jamfile.v2s, probably to link with or build a static library. On first view, 
it's odd that the build system depends on backward code.

2. On second look, you see that BOOST_PYTHON_STATIC_LINK is completely unused 
and similarly undocumented, in any case defining it is not necessary for 
Boost itself.

3. The macro BOOST_PYTHON_DYNAMIC_LIB is also of questionable use. It is used 
in that file to setup auto linking and symbol visibility for a dynamic 
library, but otherwise it is unused. Actually, compare that to 
config/user.hpp, which says that you should use either of 
BOOST_{PYTHON,ALL}_DYN_LINK to get dynamic linking.

4. Speaking about config/user.hpp, there is no documented way to specify 
static linking. I think some libraries use e.g. the _DLL macro on MS' 
compiler to default to dynamic linking and otherwise assume static linking. 
Boost.Python instead assumes dynamic linking when nothing is specified and 
the only way to get static linking is by defining an otherwise undocumented 
macro.

Suggested resolution:
1. Remove above quoted lines. They have been there since 2002 (SVN revisions 
12083, 12146, 13462), and any code relying on undocumented backward compat 
code for such a long time is broken anyway (yes, sadly, that includes Boost 
itself sadly).
2. Replace checks for BOOST_PYTHON_DYNAMIC_LIB with checks for the macros 
documented in config/user.hpp.
3. Document BOOST_{ALL,foo}_STATIC_LINK as guaranteed way to get statically 
linked libraries in config/user.hpp.
4. Maybe introduce a header config/guess_linkage.hpp which will define 
BOOST_ALL_STATIC_LINK or BOOST_ALL_DYNAMIC_LINK based on heuristics like e.g. 
_DLL under win32, unless either of these two is already defined. I think that 
such heuristics already are in place in some libraries, but they should 
actually be central.

I'd start off with 1-3 and then see what breaks. Step 4 will require that 
checks are changed so that they look like this:

  if (ALL_DYN_LINK|FOO_DYN_LINK) && !FOO_STATIC_LINK
    // use dynamic linking
  else
    // use static linking
  endif

instead of just like this:

  if (ALL_DYN_LINK|FOO_DYN_LINK)
    // use dynamic linking
  else
    // use static linking
  endif

so that the detected default does not override an explicitly set linkage.

Comments anyone?

Uli