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

[Arno Rehn]

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
> 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.
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
arno at arnorehn.de