From: Alan W. I. <ir...@be...> - 2009-06-01 21:53:00
|
On 2009-06-01 16:07-0400 Hazen Babcock wrote: > [...]a sketch of how you'd tackle this problem [building the new pyqt example] using the new build system would be appreciated :). Hi Hazen: I am going to post my reply to your question on list because I believe others will be interested in my answer. The important thing to remember is that the build system for the installed examples runs independently of the build system for the PLplot core build, but core build targets and variables are passed to the installed examples build system using EXPORT of targets, configuration of examples/plplot_configure.cmake_installed_examples.in (which ends up as cmake/modules/plplot_configure.cmake in the installed examples tree), and copying of certain unconfigured key files from the source tree such as examples/CMakeLists.txt_installed_examples and examples/c/CMakeLists.txt_installed_examples_c which end up as CMakeLists.txt and c/CMakeLists.txt in the installed examples tree. Revision 10023 is a fairly useful template for what needs to be done in general to add a build of one particular installed example (qt_example in this case) to this new build system. * The qt target required to build qt_example is EXPORTed from the PLplot core build in drivers/CMakeLists.txt. examples/CMakeLists.txt_installed_examples already implements the import of all such EXPORTed targets into the new build system using the "include(export_plplot)" command. * examples/plplot_configure.cmake_installed_examples.in is modified to configure some additional core CMake variables to be used in the installed examples build system to help build qt_example. * examples/c++/CMakeLists.txt_installed_examples_cxx (which is copied to c/CMakeLists.txt in the installed examples tree ) is modified to do the actual build of qt_example using the targets and CMake variables that are available from the core build as well as anything independent that it needs to do itself. A complication for this qt_example case was I needed access to the qt4_wrap_cpp macro. Thus, as documented in examples/c++/CMakeLists.txt_installed_examples_cxx, I had to find Qt4 all over again to get access to that macro (with some care to make sure it was the same as the Qt4 used in the core version), but normally if you don't need such cmake system macros, you would just pass variables like QT_LIBRARIES directly from the core build without having to determine them all over again with a system Find module. Thanks for your interest in using the new build system for the installed examples to build your new pyqt example. I hope the above general explanation will help you toward that goal. I will take a look at that example this afternoon to see if there is anything more I can say to you (off list) to help you with that specific build. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-06 23:37:22
|
Alan W. Irwin wrote: > Hi Hazen: > > I sometimes do my best work while asleep. :-) > > Anyhow, I woke up this morning with an improved idea about how your pyqt > example should really be handled. I was overfocussed yesterday on the > build > of the plplot_pyqt extension module and assumed that should happen in the > new build system, but instead you should just simply build and install the > plplot_pyqt extension module as part of the ordinary core build. > > So I suggest you use svn move to move everything except pyqt_test.py from > examples/plplot_pyqt to bindings/python/pyqt4 and initially proceed using > that directory along the lines I mentioned to make the touch + python > config.py work as part of the core build followed up (after consulting > again > with me) by the finishing steps I mentioned to actually build and install > the plplot_pyqt extension module as part of the core build using the source > files that are generated (indirectly via "python config.py") by sip. > > With this approach there is nothing extra to build in the new build system > for the installed examples at all, and your pyqt_test.py example would > simply use the plplot_pyqt extension module that is built and installed by > the plplot core build. IOW, pyqt_test.py would be handled from the core > build system perspective very similarly to the way that prova.py is dealt > with. > > I hope this new idea makes better sense to you than the previous idea. In > any case, I think I have a clear overview now of exactly what needs to be > done, and I would be happy to answer any further questions you may have > about that overview. I've moved the pyqt4 bindings into bindings/python/pyqt4 and I have started in on trying to figure out how to get them built. I was able to create the required config.py.in using the cmake file() command. Now I'm struggling to get the "python config.py" command to happen. Is add_custom_command() the right way to do this? Do I understand correctly that source_dir/bindings/python/pyqt4/CMakeLists.txt is used by cmake to create the Makefile in binary_dir/bindings/python/pyqt4? thanks, -Hazen |
From: Alan W. I. <ir...@be...> - 2009-06-07 03:46:34
|
On 2009-06-06 19:36-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> Hi Hazen: >> >> I sometimes do my best work while asleep. :-) >> >> Anyhow, I woke up this morning with an improved idea about how your pyqt >> example should really be handled. I was overfocussed yesterday on the >> build >> of the plplot_pyqt extension module and assumed that should happen in the >> new build system, but instead you should just simply build and install the >> plplot_pyqt extension module as part of the ordinary core build. >> >> So I suggest you use svn move to move everything except pyqt_test.py from >> examples/plplot_pyqt to bindings/python/pyqt4 and initially proceed using >> that directory along the lines I mentioned to make the touch + python >> config.py work as part of the core build followed up (after consulting >> again >> with me) by the finishing steps I mentioned to actually build and install >> the plplot_pyqt extension module as part of the core build using the source >> files that are generated (indirectly via "python config.py") by sip. >> >> With this approach there is nothing extra to build in the new build system >> for the installed examples at all, and your pyqt_test.py example would >> simply use the plplot_pyqt extension module that is built and installed by >> the plplot core build. IOW, pyqt_test.py would be handled from the core >> build system perspective very similarly to the way that prova.py is dealt >> with. >> >> I hope this new idea makes better sense to you than the previous idea. In >> any case, I think I have a clear overview now of exactly what needs to be >> done, and I would be happy to answer any further questions you may have >> about that overview. > > I've moved the pyqt4 bindings into bindings/python/pyqt4 and I have started > in on trying to figure out how to get them built. I was able to create the > required config.py.in using the cmake file() command. Now I'm struggling to > get the "python config.py" command to happen. Is add_custom_command() the > right way to do this? Hi Hazen: I am glad you put the question on list since these build system details concerning add_custom_command (and add_custom_target) are important for all PLplot developers if they want to understand or modify our build system Here is what you have now: file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/config.py.in "") add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) That is close, but here is how I would replace that: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/config.py.in COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/config.py.in COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/config.py ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip ) add_custom_target(generate_pyqt_source DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/config.py.in ) Note the first COMMAND uses cmake -E touch to create an empty file in a cross-platform way or, if that file exists already, update its create time. (Your file command creates the file once at cmake time and never updates its creation time again so I prefer to use cmake -E at _make_ time whenever possible to keep dependencies working correctly.) Note, I have changed OUTPUT from a directory (which I don't think will work) to a representative file created by the combination of COMMANDS. I chose config.py.in, but it could have also been one of the other generated files such as sipplplot_pyqtQtExtWidget.cpp. I have also added some file DEPENDS so that this custom command will get re-executed whenever one of these DEPENDS files is updated to a later date (say through editing) then the create date of the config.py.in that was created the last time the custom command is run. Finally, no add_custom_command runs by itself. It must be depended on (as in generate_pyqt_source above) by a custom target. > Do I understand correctly that > source_dir/bindings/python/pyqt4/CMakeLists.txt is used by cmake to create > the Makefile in binary_dir/bindings/python/pyqt4? CMake creates a huge web of Makefiles that interact with each other. It takes a lot of effort to figure out that web, but the bottom line is you can execute any custom target by make target_name run from either the top-level build directory or the appropriate sub_directory (bindings/python/pyqt4 in this case) of that top-level directory. Run "make help" in any build-tree directory to see the list of targets that are accessible from there. After you make the above change, generate_pyqt_source should be available, and if you run make VERBOSE=1 generate_pyqt_source you should see all the commands in the custom_command run as a dependency of that target. Furthermore, if you repeat the make command, the custom_command will not be run if you haven't updated either config.py or plplot_pyqt.sip since their dates are less than the date of the config.py.in file. IOW, it does the right thing with regard to file dependencies. Once you confirm that the above works, then the next thing is to collect all the names of the generated *.cpp files as a CMake list, and (a) use set_source_files_properties to set GENERATED to ON for all those files and (b) build the extension module using the add_library(library_name MODULE ...) command, and (c) install that created module in the correct position (following what is done in bindings/python/CMakeLists.txt for installing the extension modules created there). That should finish the new binding. The only thing left to do after that is to change your pyqt_test.py example to access the installed extension module location by importing the installed examples/python/plplot_python_start.py and install pyqt_test.py into examples/python/ (unless you have a number of pyqt4 examples in mind that you want to install in their own subdirectory of the installed examples/python). The above is pretty long because I think I have covered all the steps necessary to finish everything with your new pyqt4 bindings and your new pyqt4 example. Anyhow, good luck, and if you have any further questions, I would be happy to answer them. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-08 15:11:32
|
Alan W. Irwin wrote: > On 2009-06-06 19:36-0400 Hazen Babcock wrote: >> I've moved the pyqt4 bindings into bindings/python/pyqt4 and I have started >> in on trying to figure out how to get them built. I was able to create the >> required config.py.in using the cmake file() command. Now I'm struggling to >> get the "python config.py" command to happen. Is add_custom_command() the >> right way to do this? > > Hi Hazen: > > I am glad you put the question on list since these build system details > concerning add_custom_command (and add_custom_target) are important for all > PLplot developers if they want to understand or modify our build system > > Here is what you have now: > > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/config.py.in "") > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py > WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} > ) > > That is close, but here > is how I would replace that: > > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py > WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} > DEPENDS > ${CMAKE_CURRENT_SOURCE_DIR}/config.py > ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip > ) > > add_custom_target(generate_pyqt_source > DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > ) Hi Alan, Thanks for the help and suggestions! I also added: COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip ${CMAKE_CURRENT_BINARY_DIR}/. Since this seemed like the right thing to do to get the "python config.py" command to work when executed in WORKING_DIRECTORY. One result of executing "python config.py" is that it generates its own Makefile in WORKING_DIRECTORY. This overwrites the Makefile that was generated by CMake. What is the best way to handle this? -Hazen |
From: Alan W. I. <ir...@be...> - 2009-06-08 18:14:29
|
Hi Hazen: On 2009-06-08 11:11-0400 Hazen Babcock wrote: > Hi Alan, > > Thanks for the help and suggestions! I also added: > > COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip > ${CMAKE_CURRENT_BINARY_DIR}/. > > Since this seemed like the right thing to do to get the "python config.py" > command to work when executed in WORKING_DIRECTORY. > > One result of executing "python config.py" is that it generates its own > Makefile in WORKING_DIRECTORY. This overwrites the Makefile that was > generated by CMake. What is the best way to handle this? Ugh. I forgot about that nameclash with the "python config.py" approach. You should be able to work around that by creating a python_config subdirectory at cmake time using the file(MAKE_DIRECTORY ...) command and using that subdirectory for your working directory instead. (Note, in this case I prefer file(MAKE_DIRECTORY...) at cmake time rather than cmake -E make_directory at make time.) The created *.cpp files would then be in the examples/python/pyqt4/python_config directory along with the unused Makefile generated by "python config.py". Note, the extension module would still be built from examples/python/pyqt4 using the intact CMake-generated Makefile there using the generated source file names with the python_config subdirectory prepended to the name) so I think this idea will work to get rid of the name clash. If there is some further problem with this approach we could always switch to running a pure sip custom command (with sip options appropriately configured by cmake similar to what config.py does now) to generate the source files. I actually don't think changing to pure sip will be necessary for now, but if that idea appeals to you we could certainly go there after you get the current "python config.py" approach to work all the way through to generating the extension module. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-15 16:33:38
|
Alan W. Irwin wrote: > > Hi Hazen: > > I am glad you put the question on list since these build system details > concerning add_custom_command (and add_custom_target) are important for all > PLplot developers if they want to understand or modify our build system > > Here is what you have now: > > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/config.py.in "") > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py > WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} > ) > > That is close, but here > is how I would replace that: > > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/config.py > WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} > DEPENDS > ${CMAKE_CURRENT_SOURCE_DIR}/config.py > ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip > ) > > add_custom_target(generate_pyqt_source > DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/config.py.in > ) > > Note the first COMMAND uses cmake -E touch to create an empty file in a > cross-platform way or, if that file exists already, update its create time. > (Your file command creates the file once at cmake time and never updates its > creation time again so I prefer to use cmake -E at _make_ time whenever > possible to keep dependencies working correctly.) > > Note, I have changed OUTPUT from a directory (which I don't think will work) > to a representative file created by the combination of COMMANDS. I chose > config.py.in, but it could have also been one of the other generated files > such as sipplplot_pyqtQtExtWidget.cpp. I have also added some file DEPENDS > so that this custom command will get re-executed whenever one of these > DEPENDS files is updated to a later date (say through editing) then the > create date of the config.py.in that was created the last time the custom > command is run. > > Finally, no add_custom_command runs by itself. It must be depended on > (as in generate_pyqt_source above) by a custom target. > >> Do I understand correctly that >> source_dir/bindings/python/pyqt4/CMakeLists.txt is used by cmake to create >> the Makefile in binary_dir/bindings/python/pyqt4? > > CMake creates a huge web of Makefiles that interact with each other. It takes > a lot of effort to figure out that web, but the bottom line is you can execute > any custom target by > > make target_name > > run from either the top-level build directory or the appropriate sub_directory > (bindings/python/pyqt4 in this case) of that top-level directory. > > Run "make help" in any build-tree directory to see the list of targets that > are accessible from there. After you make the above change, > generate_pyqt_source should be available, and if you run > > make VERBOSE=1 generate_pyqt_source > > you should see all the commands in the custom_command run as a dependency of > that target. Furthermore, if you repeat the make command, the > custom_command will not be run if you haven't updated either config.py or > plplot_pyqt.sip since their dates are less than the date of the config.py.in > file. IOW, it does the right thing with regard to file dependencies. > > Once you confirm that the above works, then the next thing is to collect all > the names of the generated *.cpp files as a CMake list, and (a) use > set_source_files_properties to set GENERATED to ON for all those files and > (b) build the extension module using the add_library(library_name MODULE > ...) command, and (c) install that created module in the correct position > (following what is done in bindings/python/CMakeLists.txt for installing the > extension modules created there). That should finish the new binding. > > The only thing left to do after that is to change your pyqt_test.py example > to access the installed extension module location by importing the installed > examples/python/plplot_python_start.py and install pyqt_test.py into > examples/python/ (unless you have a number of pyqt4 examples in mind that > you want to install in their own subdirectory of the installed > examples/python). > > The above is pretty long because I think I have covered all the steps > necessary to finish everything with your new pyqt4 bindings and your new > pyqt4 example. Anyhow, good luck, and if you have any further questions, I > would be happy to answer them. 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} ) A side question, is it possible to wildcard for generated files, i.e. instead of: set_source_files_properties( ${PYQT4_CONFIG_DIRECTORY}/sipAPIplplot_pyqt.h ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtcmodule.cpp ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtExtWidget.cpp ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLDriver.cpp ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLWidget.cpp PROPERTIES GENERATED ON ) Something like: set_source_files_properties( ${PYQT4_CONFIG_DIRECTORY}/*.h ${PYQT4_CONFIG_DIRECTORY}/*.cpp PROPERTIES GENERATED ON ) thanks! -Hazen |
From: Alan W. I. <ir...@be...> - 2009-06-15 17:09:01
|
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). > > > A side question, is it possible to wildcard for generated files, i.e. instead > of: > > set_source_files_properties( > ${PYQT4_CONFIG_DIRECTORY}/sipAPIplplot_pyqt.h > ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtcmodule.cpp > ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtExtWidget.cpp > ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLDriver.cpp > ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLWidget.cpp > PROPERTIES GENERATED ON > ) > > Something like: > set_source_files_properties( > ${PYQT4_CONFIG_DIRECTORY}/*.h > ${PYQT4_CONFIG_DIRECTORY}/*.cpp > PROPERTIES GENERATED ON > ) It is possible to run arbitrary cmake scripts at make time (when the above files are generated) so I think the answer to your question must be yes although it would be a bit complicated. Is there any reason why you expect those file names to change much? For other source files generated at run time (such as our python and java bindings) we simply list out the source files as needed like you did above in your first version of set_source_files_properties. I far prefer that explicit approach if the file names are not expected to change much. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-15 20:15:12
|
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. >> >> A side question, is it possible to wildcard for generated files, i.e. instead >> of: >> >> set_source_files_properties( >> ${PYQT4_CONFIG_DIRECTORY}/sipAPIplplot_pyqt.h >> ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtcmodule.cpp >> ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtExtWidget.cpp >> ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLDriver.cpp >> ${PYQT4_CONFIG_DIRECTORY}/sipplplot_pyqtQtPLWidget.cpp >> PROPERTIES GENERATED ON >> ) >> >> Something like: >> set_source_files_properties( >> ${PYQT4_CONFIG_DIRECTORY}/*.h >> ${PYQT4_CONFIG_DIRECTORY}/*.cpp >> PROPERTIES GENERATED ON >> ) > > It is possible to run arbitrary cmake scripts at make time (when the above > files are generated) so I think the answer to your question must be yes > although it would be a bit complicated. > > Is there any reason why you expect those file names to change much? For > other source files generated at run time (such as our python and java > bindings) we simply list out the source files as needed like you did above > in your first version of set_source_files_properties. I far prefer that > explicit approach if the file names are not expected to change much. No I don't think they will change very often so I will just leave this part as is. 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? (2) I seem to have to explicitly do "make generate_pyqt_source" before doing "make". How do I make that happen automatically? -Hazen |
From: Alan W. I. <ir...@be...> - 2009-06-15 21:08:40
|
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 __________________________ |
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 |
From: Alan W. I. <ir...@be...> - 2009-06-16 08:00:09
|
On 2009-06-15 17:52-0400 Hazen Babcock wrote: > Ok. I just checked in my progress so far. I'm still struggling to get > plplot_pyqt.so correctly linked to qt.so. I made some additional CMake logic tweaks that I thought were necessary (revision 10049). But for now a dirty build is required to get everything to work (see the associated commit message for details). It is possible that attempting to re-use as a cmake library the shared object qt.so that is actually built as a cmake module is just not a reliable approach on Linux and may not work at all on other platforms where there are bigger distinctions between cmake modules and cmake libraries. I will sleep on it, but for now I am leaning toward solving this problem by building and installing a real plplot_qt library using the identical source code that is used to build the module, qt.so. I will sort this out tomorrow (Tuesday). 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 __________________________ |