On 2013-01-05 12:06+0100 Arjen Markus wrote:
> Hi Alan,
>
> I have updated two Wiki pages to describe the issue.
> I hope I have provided enough details so that others will
> understand it. So, if someone can review this, that would be
> great.
>
> The code you quoted is exactly what brings the dependency
> of python27_d.lib into the Python bindings for a Debug build
> with the MS Visual C/C++ compiler. And only in that particular
> combination! Code in the CMake FindPython module is related to
> this specific handling.
Hi Arjen:
Now that you have explained the details, I suspect this issue is
caused by our build system's incomplete use of results returned
by CMake's FindPythonLibs.cmake module.
But first I looked at how FindQt4.cmake handled the possibility
of multiple qt library versions being installed. And here is
the smooth way they handle it with the following code fragment:
if (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
set(QT_${basename}_LIBRARY optimized ${QT_${basename}_LIBRARY_RELEASE}
debug ${QT_${basename}_LIBRARY_DEBUG})
So the result can just be plugged into the target_link_libraries command
with the optimized and debug keywords for that command completely
specified with the correct name of both the optimized and debug versions of
the libraries. And the result is the user can specify any
CMAKE_BUILD_TYPE and the correct Qt linking is done just using
the $QT_LIBRARIES} variable in target_link_libraries.
But apparently such user-convenient logic is not included in
FindPythonLibs.cmake. There is no mention of CMAKE_BUILD_TYPE there
or the optimized and debug keywords that occur for the
FindQt4.cmake case.
Instead that module supplies both PYTHON_DEBUG_LIBRARIES (labelled as
deprecated) and PYTHON_LIBRARIES. So my guess is our build system
(and also the ephcom build system where I propagated what is currently
done for PLplot) should be modified such that are current
target_link_libraries(<python_target_name> ${PYTHON_LIBRARIES})
command(s) should be replaced by
target_link_libraries(<python_target_name> general ${PYTHON_LIBRARIES}
optimized ${PYTHON_LIBRARIES}
debug ${PYTHON_DEBUG_LIBRARIES})
Would you be willing to try this change to the PLplot and/or ephcom
build systems to see if it solves the issue for you? (Of course, on
Linux, PYTHON_DEBUG_LIBRARIES is not defined at all by
FindPythonLibs.cmake so if the above change works for you, we will
have to do set PYTHON_DEBUG_LIBRARIES to PYTHON_LIBRARIES if
PYTHON_DEBUG_LIBRARIES is not defined, but don't worry about that now
for your Windows test.
Of course, I am concerned about that deprecated label for the
PYTHON_DEBUG_LIBRARIES variable so I am also going to put a question
to the cmake list about this situation to see if anybody can suggest
better logic than the above.
By the way, uou have stated CMAKE_BUILD_TYPE=Debug is the default for
you, but I am wondering if that is a default imposed by your build
scripts rather than cmake itself. Certainly on Linux with the
"Unix Makefiles" generator (and also Wine with the "MSYS Makefiles"
generator)
if I don't specify CMAKE_BUILD_TYPE at all,
the CMakeCache.txt file has
CMAKE_BUILD_TYPE:STRING=
by default, i.e., it is set to an empty string by default. So I
suggest you should look at your build scripts to make sure
CMAKE_BUILD_TYPE=Debug is not being set somewhere. Another
possibility is the "NMake Makefiles" generator is setting
CMAKE_BUILD_TYPE:STRING=Debug by default in which case I think you
could impose "-DCMAKE_BUILD_TYPE:STRING=" as a cmake option to force
CMAKE_BUILD_TYPE to be empty in the cache.
Anyhow, once CMAKE_BUILD_TYPE is empty in your cache (as happens by
default for both the "Unix Makefiles" and "MSYS Makefiles" cases), I
predict that the C macro _DEBUG will not be #defined and the present
unmodified build systems will just work for you (as it does
when you specify -DCMAKE_BUILD_TYPE:STRING=Release).
But avoiding the case where CMAKE_BUILD_TYPE=Debug is just a
workaround, and I think the right solution for when the user asks for
CMAKE_BUILD_TYPE=Debug is to use the "general", "optimized", and
"debug" keywords in the target_link_libraries for all python
linking. So I hope you are willing to test the possibility and
I will also ask for comments about that possibility on the
cmake list.
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
__________________________
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
