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
__________________________
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
