From: Hazen B. <hba...@ma...> - 2009-06-15 21:52:17
|
Alan W. Irwin wrote: > On 2009-06-15 14:57-0400 Hazen Babcock wrote: > >> Alan W. Irwin wrote: >>> On 2009-06-15 12:30-0400 Hazen Babcock wrote: >>> >>>> Hi Alan, >>>> >>>> I'm getting closer, but I can see that there is at least one missing >>>> dependency. I need to link to the qt.so library that is generated by our >>>> Qt bindings, but I can't figure out what its name is in our build system. >>>> At present I have this: >>>> >>>> target_link_libraries( >>>> plplot_pyqt >>>> plplot${LIB_TAG} >>>> ${QT_LIBRARIES} >>>> ) >>>> >>>> And I think I need something like this: >>>> >>>> target_link_libraries( >>>> plplot_pyqt >>>> ${PLPLOT_QT_LIBRARY} >>>> plplot${LIB_TAG} >>>> ${QT_LIBRARIES} >>>> ) >>> I suggest trying something like this: >>> >>> if(ENABLE_DYNDRIVERS) >>> target_link_libraries( >>> plplot_pyqt >>> qt >>> plplot${LIB_TAG} >>> ${QT_LIBRARIES} >>> ) >>> else(ENABLE_DYNDRIVERS) >>> target_link_libraries( >>> plplot_pyqt >>> plplot${LIB_TAG} >>> ${QT_LIBRARIES} >>> ) >>> endif(ENABLE_DYNDRIVERS) >>> >>> "qt" is the target name for the qt device driver build for the >>> ENABLE_DYNDRIVERS case. So I think if you insert "qt" in the >>> target_link_libraries list for that case, cmake will do the rest. Of >>> course, if ENABLE_DYNDRIVERS is OFF, you have to treat that as a separate >>> case since there is no qt target name and the qt device code is part of the >>> PLplot core library (referenced by the plplot${LIB_TAG} target name above). >> This works in that it causes qt to get built first but it still does not seem >> to get linked correctly. I also tried adding: >> >> include_directories( >> ${CMAKE_BINARY_DIR}/drivers >> ) >> >> Since that is the location of qt.so but that did not seem to help. > > The include_directories command is to help locate compiler headers in the > build tree so that idea won't work for this purpose. > > I believe the problem here is that you are attempting to use qt.so as a > library rather than as the shared object (what cmake calls a module) that is > normally dynamically loaded by PLplot at run time. The difference in > properties between how cmake libraries and cmake modules are treated by > cmake may be confusing cmake about how to link results that depend on qt.so > as a library. > > I had similar problems with building qt_example with the new build > system for the installed examples. There (see > examples/c++/CMakeLists.txt_installed_examples_cxx) I used the target > PROPERTY, IMPORTED_LOCATION_NOCONFIG, to get the location (full path > name) to use for target_link_libraries. Of course, that won't work in > this case because qt here is an internal (not exported) target. My guess, > though, is > > if(ENABLE_DYNDRIVERS) > get_target_property(qt_LOCATION qt LOCATION) > target_link_libraries( > plplot_pyqt > ${qt_LOCATION} > plplot${LIB_TAG} > ${QT_LIBRARIES} > ) > else(.... > > might work to make sure that target_link_libraries sets rpath correctly when > your plplot_pyqt python extension module is being built. > >> I also have two other issues: >> (1) plplot_pyqt.so is built as libplplot_pyqt.so >> How do I avoid getting the lib tag on the front? > > Use set_target_properties(...) to set the PREFIX to "". See how > the target plplot_widgetmodule (which is also a python extension module) > is built in bindings/python/CMakeLists.txt. > >> (2) I seem to have to explicitly do "make generate_pyqt_source" before doing >> "make". How do I make that happen automatically? > > When dependencies are a problem (as appears to be the case here) I often > find that solutions can only be found by experimentation. I suggest you go > ahead and check in your plplot_pyqt work so I can make such experiments. Ok. I just checked in my progress so far. I'm still struggling to get plplot_pyqt.so correctly linked to qt.so. Once that works though I think that we should be all set and running: ./examples/python/plplot_pyqt/pyqt_test.py should just work. -Hazen |