On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote: > On Thursday 21 January 2010, Arno Rehn wrote: > ... > > > Sorry, I was a bit busy in the last two weeks. > > > > After doing a clean build I saw that the QtGuess.txt file returned > > "[defined]" for every QT_NO_FOO define, i.e. that compilation failed for > > every test (so it also defines QT_NO_PRINTDIALOG, even though that's > > wrong). > > > > Digging through the cmake files, I found that FindQt4.cmake was changed > > between KDE 4.3 and 4.4. It now uses aliases for the Qt4 libs by > > importing them as targets (as Qt4__QTCORE, Qt4_QTGUI, etc.). > > > > Unfortunately, this completely screws QtGuess.txt, because TRY_COMPILE > > (built- in cmake command) can't handle imported targets. We can only use > > normal paths here. A workaround would be to resolve all imported targets, > > but that doesn't seem like the perfect solution to me. > > > > I'm CC'ing Alexander Neundorf, as he seems to be the guy who implemented > > the imported targets. > > If there are problems with building, don't hesitate to send a mail to > [email protected]. > I'd say this is usually a better idea for build problems than kde-packager > or kde-release-team. > > > Alexander, can you shed some light on why this was > > done and how to solve this issue best? > > On demand of developers. > We have our own copy of FindQt4.cmake, which with the time went relatively > far away from the shipping with CMake. > > We had several issues there. > Developers complained that our FindQt4.cmake didn't have all the features > of the one shipping with cmake (some libs not supported etc.). > Our FindQt4.cmake was not working properly with Qt as frameworks on OSX. > There was a lot of unnecessary special casing for Windows in our copy. > Getting too faw away from each other also means that we might become > incompatible, which also breaks applications. > > So I took the time and merged most of the changes from both side into each > other. Which also meant to always check for both release and debug > versions. This lead to the effect that QT_QTFOO_LIBRARY now could be > "optimized libQtFoo.so debug libQtFood.so". > > Now this change broke some places. > This way of specifying which lib is for release builds and which is for > debug builds is not good (which build types are considered debug, which > optimized ?) and is syntax-wise also a hack (from the POV of the cmake > devs). > > So, what is the best way to fix this. > It's to introduce imported targets for the various Qt libraries. > Then there exist library targets, which can be referenced. They can be > assigned different locations (file paths) for different buildtypes. > Dependencies can be tracked. Ah yes, I see.
> I tried to get this in as compatible as possible, there cannot be much left > now. > > Why are you using TRY_COMPILE() directly ? This is quite low-level, and I > would always advice against it directly. > There are the check_cxx_source_compiles() and check_cxx_source_runs() > macros installed with kdelibs (CheckCXXSourceCompiles.cmake and > CheckCXXSourceRuns.cmake), which both handle imported targets. > > What is speaking against using these macros ? > Both do check if a library is an imported target and if so retrieve the > path, this is implemented in > HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't depend > on any other additional KDE-specific cmake modules. I didn't try them because I thought they probably suffer from the same bug. Since I also was too lazy to look at their code, I didn't recognize that they work around it. Now that it doesn't seem to be a problem for the macros, I think we'll go with CheckCXXSourceCompiles.cmake. > Also, I actually would be happy if you could file this as a bug report in > the cmake bugtracker (http://public.kitware.com/Bugs) that try_compile() > doesn't handle imported targets. You've already done that yourself, nearly one year ago ;) http://public.kitware.com/Bug/view.php?id=8761 The bug's still open, though. -- Arno Rehn [email protected] _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
