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.
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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
