[Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
arno at arnorehn.de
Thu Jan 21 23:09:36 CET 2010
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
> 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
> 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
> 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 ;)
The bug's still open, though.
arno at arnorehn.de
More information about the release-team