On Sat, May 09, 2009 at 01:18:17PM -0700, Alan Irwin wrote:
> 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.
Alan, I agree with your analysis, although I hadn't noticed the bug you
mention which leads to multiple libraries listed after a single debug tag.
I must admit that all I looked at was the qt_LIB_DEPENDS in CMakeCache.txt
where all the non-QT libraries are marked as general. Do you see this as well?
If so, then I suspect that cmake treats any library without a tag as a general
option. If the general tag is not explicitly used at this stage it would explain
why
1) everything just "works" for the general case without any explicit removal
of the general tag.
2) Your "bug" is not a bug, but your analysis of the output is not quite
correct.
> 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.
For each case the first regex is essentially <tag>;*; which deletes the tag and
the following library. The second regex only deletes the tag. This does not
work
if your intepretation is correct, but does work if my alternative is correct.
In the worst case my version would leave extra libraries in place.
Either way, the current implementation needs checking as it is possible not
correct.
Andrew
------------------------------------------------------------------------------
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
