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

[Arno Rehn]

On Thursday 21 January 2010 14:13:27 Richard Dale wrote:
> On Thursday 21 January 2010 01:03:55 pm Dirk Mueller wrote:
> > On Thursday 21 January 2010, Richard Dale wrote:
> > > Certainly we didn't need the KDE 4.4 release to be branched off from
> > > the trunk a month before the actual release, while we are right in the
> > > middle of trying to sort out kdebindings.
> >
> > Hi Richard,
> >
> > I don't understand - this is exactly what happened - we've branched from
> >  trunk one month before the targetted final release.
> 
> Yes, but what I meant was that for kdebindings that doesn't make sense. If
>  you are working on a KDE application then it is a good idea to be able to
>  start adding new features to the trunk while fixing things in the 4.4
>  branch a month before the release. But we don't even quite have the time
>  to fix the 4.4 branch, let alone be adding things for the 4.5 release in
>  the trunk at the moment. So I think splitting off the 4.4 release from
>  trunk about a week before the final release would be best for kdebindings.
> 
> > How can we get kdebindings to build for RC2? This is currently blocking
> > the release.
> >
> > there are several reports on kde-packager@ and release-team@ about this,
> > I can collect my own list of compile errors, I just don't know how to
> > solve them.
> 
> I had a look a the compile error about the printer method, and there is
> supposed to be a configure check for the Smoke libs generation that tests
>  for printer functionality built in the Qt libs. It looks as though there
>  is a problem with that. Arno Rehn is the expert on the bindings generator,
>  but he doesn't seem to be around at the moment.
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. Alexander, can you shed some light on why this was done and 
how to solve this issue best?

-- 
Arno Rehn
arno at arnorehn.de