Summary: | kdebindings 4.1 mixes up Python and Ruby bindings | ||
---|---|---|---|
Product: | [Developer tools] bindings | Reporter: | Kevin Kofler <kevin.kofler> |
Component: | general | Assignee: | kde-bindings |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mueller, neundorf, rdieter |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Kevin Kofler
2008-07-25 22:19:49 UTC
CCing Dirk because IMHO this is a showstopper for 4.1.0! Hi Kevin, could you please attach the output of your "cmake" (those configure-part that prints details like what was found, etc.). Build logs (including cmake output) here: http://kojipkgs.fedoraproject.org/packages/kdebindings/4.1.0/3.fc9/data/logs/x86_64/build.log http://kojipkgs.fedoraproject.org/packages/kdebindings/4.1.0/3.fc10/data/logs/x86_64/build.log Well this is unexpected considering that kdebindings/python/pykde4/cmake/modules/SIPMacros.cmake explicitly uses a different logical name (_python_sip_foobar)) for this and uses SET_TARGET_PROPERTIES() to install the library with the correct name on disk. Is SIPMacros.cmake in kdebindings 4.1 being picked up correctly? I think the problem is that the physical name is the same and so one of the files gets overwritten with the other at some point during the build.
> Is SIPMacros.cmake in kdebindings 4.1 being picked up correctly?
How would I check that?
From the Ruby binding: Linking CXX shared module ../../lib/solid.so From the Python binding: Linking CXX shared library ../../lib/solid.so So yes, the 2 files both get staged in the same directory (the lib/ subdirectory of the CMake build directory) and thus overwrite each other. Good detective work. Now we just need a cmake guru who can tells us how to fix this. /me summons cmake guru ;-) SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/pykde) at the top of kdebindings/python/pykde4/CMakeLists.txt fixes it for me. But probably the same need to be made with CMAKE_ARCHIVE_OUTPUT_DIRECTORY and maybe there is even a more elegant way to prevent the need to redefine it for each binding-impl. Thanks! I'm now testing a kdebindings build with this patch: http://cvs.fedoraproject.org/viewcvs/rpms/kdebindings/devel/kdebindings-4.1.0-kde%23167450.patch?rev=1.1&view=markup (essentially your one-line fix with a comment added). does it work? :) Works with cmake 2.6 (Rawhide), not with 2.4 (Fedora 9). :-( The Rawhide build log: http://koji.fedoraproject.org/koji/getfile?taskID=740067&name=build.log > Linking CXX shared library ../../lib/pykde/solid.so and the files no longer collide. The Fedora 9 build log from the exact same specfile with the exact same patch: http://koji.fedoraproject.org/koji/getfile?taskID=740072&name=build.log > Linking CXX shared library ../../lib/solid.so [...] > *** WARNING: identical binaries are copied, not linked: > /usr/lib64/python2.5/site-packages/PyKDE4/solid.so > and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/solid.so So it looks like CMake 2.4 does not support CMAKE_LIBRARY_OUTPUT_DIRECTORY. Looking at one file from another project which uses that variable: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/CMakeLists.txt?rev=8527 we need to use LIBRARY_OUTPUT_PATH on CMake 2.4. re comment #14; y, I was just on my way to post that snippet; IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib/pykde) ELSE(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/pykde) ENDIF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) (untested cause I don't have 2.4 around any longer). yay, s/LESSER/LESS/ Thanks, testing this now: http://cvs.fedoraproject.org/viewcvs/rpms/kdebindings/devel/kdebindings-4.1.0-kde%23167450.patch?rev=1.2&view=markup (I had arrived to essentially the same thing almost at the same time (and was about to post it when I got your reply), but with "EQUAL 4" rather than "LESS 6". I changed it to your version because I hadn't committed the patch to the Fedora package CVS yet anyway.) BTW, the OpenSceneGraph folks deserve a beating for using this broken construct: IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4) - this will break the day CMake 3.0 is released. :-/ I guess I should file a bug with them. To end the OT part, I was nice and reported this: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014833.html Let this serves as an example how _not_ to check the version of CMake in KDE. ;-) The kdebinding builds with the latest patch are still running, I'll report as soon as they complete. I can report success: The patch from comment #17 fixes the problem, both on Rawhide (cmake 2.6) and on F9 (cmake 2.4). Fantastic. Very much thanks! So, now it's up to our release-dude or can I still do something to help there to get kdebindings@4.1.0 rocking?! SVN commit 837912 by mueller: fix python/ruby build mixup. Many thanks to Kevin Kofler for the analysis and the patch BUG: 167450 M +7 -0 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=837912 |