[Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded

[Alexander Neundorf]

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 
kde-buildsystem at kde.org.
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.

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.

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.

Alex