From: Alan W. I. <ir...@be...> - 2009-05-09 20:18:21
|
On 2009-05-09 11:09+0100 Andrew Ross wrote: > On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote: >> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my >> changes dealt with the QT_LIBRARIES issue directly, I am wondering whether >> we should revert your change (because I am not quite sure whether that logic >> will always work properly) or just leave it in case some other library ever >> exhibits the same issue that has just been fixed for QT_LIBRARIES. >> >> I would like to keep my changes since they do address the QT_LIBRARIES issue >> in a way that I understand. We could also keep your changes since they >> peacefully coexists with mine. However, yours is no longer necessary so I >> leave it to you whether to revert it or not. > > Alan, > > As you say, they should coexist. My patch simply removes any optimized tags and > libraries for debug builds, and otherwise removes any debug tags and libraries. > It then removes the remaining tags which are not needed for pkg-config. It > works for me. I'll comment it out for now, but leave the code there, then if > the need arises for other libraries we can easily reinstate. It's only a > relatively small patch. Hi Andrew: I would like to discuss some of the background for my fix since there is a fair bit of interpretation and cmake code reading involved. At the end I have a question for you in regard to your regexes. If you dig into FindQt4.cmake and UseQt4.cmake, the latter shows that QT_LIBRARIES is made up of individual ${QT_${module}_LIBRARY} values and ${QT_${module}_LIB_DEPENDENCIES} values. FindQt4.cmake sets both ${QT_${module}_LIBRARY} and ${QT_${module}_LIBRARIES} forms but the latter form is completely ignored (which sure is a misleading form of variable name!) when forming QT_LIBRARIES. Furthermore, FindQt4.cmake sets the ${QT_${module}_LIB_DEPENDENCIES} form of variables. It appears that the Qt4 libraries are released as either RELEASE or DEBUG versions. The macro _QT4_ADJUST_LIB_VARS in FindQt4.cmake sets the LIBRARY form of variable to the RELEASE version of Qt4 library if that is all there is and similarly it sets that form of variable to the DEBUG version of Qt4 library if that is all there is. Finally, if both versions of Qt4 library exist, then there are two code paths possible. If CMAKE_BUILD_TYPE is set (to any value) then the LIBRARY form of variable is set to both the RELEASE and DEBUG versions of Qt4 libraries with each indicated by the keywords "optimized" and "debug". If the CMAKE_BUILD_TYPE is not set the LIBRARY form of variable is set to RELEASE version of the Qt4 libraries. For those cases where the debug keyword is used, it is used after the optimized keyword so that the appended ${QT_${module}_LIB_DEPENDENCIES} values are interpreted _only_ as debug libraries or generaly (no keyword) libraries, but not as optimized libraries. I think that is a bug, but I am not sure. The results obtained on my system support this partial analysis. If any value of CMAKE_BUILD_TYPE is specified via a cmake option, then the QT_LIBRARIES list delivered by FindQt4.cmake is (rearranged for clarity) optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl If you do not specify CMAKE_BUILD_TYPE you get the debug version (without the debug keyword). Note, the extra set of libraries for the debug version (and general version) I attribute to the code quirk (or bug) I noted above for how ${QT_${module}_LIB_DEPENDENCIES} variables are just appended to what comes before with no regard to whether it has keywords or not. Regardless of this question, I have recently (revision 9948) made the QT_LIBRARIES logic a lot safer. Only in the case of a specific request for the Release CMake_BUILD_type and non-empty QT_LIBRARIES_optimized is that keyworded subset of QT_LIBRARIES used. Otherwise, I use the QT_LIBRARIES_debug subset (if non-empty) or the QT_LIBRARIES_general subset if that is non-empty. I don't completely trust QT_LIBRARIES_optimized because it appears to be incomplete (see above discussion). However, I have checked with "ldd -r qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on Linux without any undefined variables for the downloadable Qt-4.5.1 available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not have some of the missing libraries, they show up in ldd anyway (which is why there is no undefined symbols). So I am going to leave in this "Release" possibility for now. But if there are problems with -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I think is a bug in FindQt4.cmake), then I will only use QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug subset and the QT_LIBRARIES_general subset are empty. Getting back to your own (commented out) solution, it is good to have that in reserve in case some other Find module starts passing back keyworded library information. However, I am having trouble figuring out what your commented out regex's would do. I think you are just dropping the keywords rather than keyword + associated libraries like you state above. Could you let me know which interpretation of the regexes is correct? I actually think that dropping just the keywords is the safest course because if we ever need this logic the result of just dropping the keywords would be repeated libraries and extra unneeded libraries. That is a much more acceptable (and safer) result than potentially dropping a library that might be essential. 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 __________________________ |