[CMake] What is the proper cross-platform way to link the Python library?

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sat Jan 5 17:52:32 EST 2013


On several different build systems I am maintaining, 
target_link_libraries (or its swig equivalent) is used in the following way to link in the
Python library.

target_link_libraries(<python target> ${PYTHON_LIBRARIES})

where PYTHON_LIBRARIES has been set by using the FindPythonLibs find
module.  This approach works well on Unix with the "Unix Makefiles"
generator and also on Windows with the "MSYS Makefiles" generator,

But Arjen tells me this general approach fails when using the MSVC compiler
and the "NMake Makefiles" generator _and_ if he sets
CMAKE_BUILD_TYPE:STRING=Debug.

His further analysis of the
official Python release for Windows helps clarify the issue:
The pyconfig.h header file for that official release contains the following
code fragment:

/* For an MSVC DLL, we can nominate the .lib files used by extensions */
#ifdef MS_COREDLL
#       ifndef Py_BUILD_CORE /* not building the core - must be an ext */
#               if defined(_MSC_VER)
                         /* So MSVC users need not specify the .lib file in
                         their Makefile (other compilers are generally
                         taken care of by distutils.) */
#                       ifdef _DEBUG
#                               pragma comment(lib,"python27_d.lib")
#                       else
#                               pragma comment(lib,"python27.lib")
#                       endif /* _DEBUG */
#               endif /* _MSC_VER */
#       endif /* Py_BUILD_CORE */
#endif /* MS_COREDLL */

Arjen tells me that what this means is for certain circumstances
(apparently fulfilled for the MSVC compiler and when
CMAKE_BUILD_TYPE:STRING=Debug is set) the python debug library
(python27_d.lib) is automatically linked.  But that clashes with the
cmake result for the above target_link_libraries command which always
links in the ordinary Python library since FindPythonLibs returns a
PYTHON_LIBRARIES variable which includes no "general", "optimized", or
"debug" keywords.  (This behaviour for FindPythonLibs is in sharp
contrast with, e.g., the user-friendly FindQt4 module which returns
the QT_LIBRARIES variable which does include the optimized and debug
keywords when appropriate for certain platforms.)

So I am thinking of replacing the above target_link_libraries code
by the following:

if(NOT PYTHON_DEBUG_LIBRARIES)
   # Required for platforms like Linux that don't set PYTHON_DEBUG_LIBRARIES
   set(PYTHON_DEBUG_LIBRARIES ${PYTHON_LIBRARIES})
endif(NOT PYTHON_DEBUG_LIBRARIES)

target_link_libraries(<python target>
   general ${PYTHON_LIBRARIES}
   optimized ${PYTHON_LIBRARIES}
   debug ${PYTHON_DEBUG_LIBRARIES}
   )

Is this the correct general cross-platform approach that should be
used for linking the python library (at least until FindPythonLibs
returns a more user-friendly PYTHON_LIBRARIES result) or is there a
better alternative? I ask this question because the
PYTHON_DEBUG_LIBRARIES variable is documented as deprecated.  But I
don't know any other possibility than using that deprecated variable
on Windows with the MSVC compiler and CMAKE_BUILD_TYPE:STRING=Debug so
comments on the above suggested approach (especially from whichever
CMake developer is responsible for FindPythonLibs) would be
appreciated.


Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list