Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Saturday 23 January 2010, Arno Rehn wrote:
> On Friday 22 January 2010 17:52:12 Alexander Neundorf wrote:
> > Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
> >
> > > /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> > > lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
> > >
> > > I used this:
> > >
> > > include (HandleImportedTargetsInCMakeRequiredLibraries)
> > > set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH}
> > > ${QT_INCLUDE_DIR}) set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY}
> > > ${QT_QTDBUS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY}
> > > ${QT_QTOPENGL_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> > > HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIB
> > >RA RI ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
> > >
> > > What are linkInterfaceLibs? Wouldn't it be better if they weren't added
> > > to the list if they don't exist?
> >
> > Sure, that's what the patch mentioned above should do.
> > If it doesn't let's fix it.
>
> Ok, the macro works fine now. Next problem is the following:
>
> Linking CXX shared library ../../lib/libsmokekdecore.so
> /usr/bin/ld: cannot find -lQt4__QTDBUS
> collect2: ld returned 1 exit status
You're kdelibs are not current, please update them e.g. to at least rev.
1076826 from the 4.4 branch.
Let me know if yu then still have this problem (the names of the imported
targets changed from Qt4__QTFOO to Qt4::QtFoo, this needed to be done before
4.4.0)
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Friday 22 January 2010 17:52:12 Alexander Neundorf wrote:
> Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
>
> > /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> > lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
> >
> > I used this:
> >
> > include (HandleImportedTargetsInCMakeRequiredLibraries)
> > set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH}
> > ${QT_INCLUDE_DIR}) set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY}
> > ${QT_QTDBUS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY}
> > ${QT_QTOPENGL_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> > HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRA
> >RI ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
> >
> > What are linkInterfaceLibs? Wouldn't it be better if they weren't added
> > to the list if they don't exist?
>
> Sure, that's what the patch mentioned above should do.
> If it doesn't let's fix it.
Ok, the macro works fine now. Next problem is the following:
Linking CXX shared library ../../lib/libsmokekdecore.so
/usr/bin/ld: cannot find -lQt4__QTDBUS
collect2: ld returned 1 exit status
the cmake code is:
target_link_libraries(smokekdecore
${QT_QTCORE_LIBRARY}
${QT_QTNETWORK_LIBRARY}
${QT_QTDBUS_LIBRARY}
${KDE4_KDECORE_LIBS}
smokeqtcore
smokeqtnetwork
smokeqtdbus
)
If I comment out the KDECORE libs, the above mentioned error goes away and I
only get a whole lot of undefined reference errors (as was to be expected). So
I guess FindKDE4Internal.cmake is doing something wrong. I just checked for
updates, but my cmake macros are up-to-date.
--
Arno Rehn
a...@arnorehn.de
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Friday 22 January 2010, Arno Rehn wrote:
> On Thursday 21 January 2010 23:31:32 Alexander Neundorf wrote:
> > On Thursday 21 January 2010, Arno Rehn wrote:
> > > On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
> >
> > ...
> >
> > > > 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.
> >
> > Let me know (tomorrow) if it doesn't work.
>
> So I just tried to make it work with
> HandleImportedTargetsInCMakeRequiredLibraries only. It fails with many of
> the following errors:
>
> CMake Error: The following variables are used in this project, but they are
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake
> files:
> _linkInterfaceLibs
> linked by target "cmTryCompileExec" in directory
> /home/pumphaus/dev/KDE/kdebindings-build2/smoke/qt/test-
> QT_NO_DEBUG/CMakeFiles/CMakeTmp
Is this with a current HandleImportedTargetsInCMakeRequiredLibraries.cmake
i.e. at least 1073213 ? This commit on January 11th should have fixed that.
http://websvn.kde.org/?view=revision&revision=1073213
Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
> /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
>
> I used this:
>
> include (HandleImportedTargetsInCMakeRequiredLibraries)
> set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH} ${QT_INCLUDE_DIR})
> set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY}
> ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY} ${QT_QTOPENGL_LIBRARY}
> ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRARI
>ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
>
> What are linkInterfaceLibs? Wouldn't it be better if they weren't added to
> the list if they don't exist?
Sure, that's what the patch mentioned above should do.
If it doesn't let's fix it.
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 January 2010 23:31:32 Alexander Neundorf wrote:
> On Thursday 21 January 2010, Arno Rehn wrote:
> > On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
>
> ...
>
> > > 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.
>
> Let me know (tomorrow) if it doesn't work.
So I just tried to make it work with
HandleImportedTargetsInCMakeRequiredLibraries only. It fails with many of the
following errors:
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
_linkInterfaceLibs
linked by target "cmTryCompileExec" in directory
/home/pumphaus/dev/KDE/kdebindings-build2/smoke/qt/test-
QT_NO_DEBUG/CMakeFiles/CMakeTmp
The macro writes the following to the result variable:
/usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
I used this:
include (HandleImportedTargetsInCMakeRequiredLibraries)
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH} ${QT_INCLUDE_DIR})
set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY}
${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY} ${QT_QTOPENGL_LIBRARY}
${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRARIES)
message("${_CMAKE_REQUIRED_LIBRARIES}")
What are linkInterfaceLibs? Wouldn't it be better if they weren't added to the
list if they don't exist?
--
Arno Rehn
a...@arnorehn.de
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 January 2010, Arno Rehn wrote: > On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote: ... > > 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. Let me know (tomorrow) if it doesn't work. > > 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 Oh, indeed. I remembered that discussion but I thought it was via email. > The bug's still open, though. Yes, I know. Feel free to add a comment in the bug report. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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-buildsys...@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 a...@arnorehn.de ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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-buildsys...@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 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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 a...@arnorehn.de ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 of January 2010 12:22:43 Richard Dale wrote: > I don't think we need a strict ban. I think the problem is that the kde > bindings release schedule is unavoidably slightly behind the KDE libraries > release schedule. However, the overall KDE release schedule doesn't take > this into account. > > 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. Not to mention that 4.4 branch actually suffers from the fact it's being created so early as not everyone is willing to backport all changes from trunk (and some changes cannot be backported) which means some developers are already commited to work in trunk in many cases while 4.4 is not even released yet. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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. 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. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
Op Thursday 21 January 2010 12:22 schreef u: > I don't think we need a strict ban. I think the problem is that the kde > bindings release schedule is unavoidably slightly behind the KDE libraries > release schedule. However, the overall KDE release schedule doesn't take this > into account. > > 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. Can you send me an email with how the release schedule should be adapted in your opinion? When I create the 4.5 schedule I can incorporate your wishes - if possible of course.. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Wednesday 20 January 2010 07:17:08 pm Simon Edwards wrote: > Hello, > > Dirk Mueller wrote: > > On Thursday 07 January 2010, Simon Edwards wrote: > >>> [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all] Error 2 > >>> make: *** [all] Error 2 > >> > >> It should work fine with a recent SIP and PyQt snapshot. > >> > >> A new stable release of PyQt is imminent, then can I up the version > >> check in CMakeLists.txt. Sorry for the inconvenience guys. > > > > Is it possible to make the bindings only use released versions of > > sip/pyqt? > > A new SIP and PyQt stable are out and PyKDE now requires it and checks > for it in CMakeLists. Although annoying, not using SIP/PyQt snapshots > during the 4.4 dev cycle would have required dropping most of the new > changes to Plasma which depend on new functionality in Qt 4.6. This is > really one of the risks of KDE requiring a bleeding edge Qt > functionality (4.6) which wasn't released until quite late in the KDE > dev cycle. Other things like PyQt depend on Qt and don't get much time > to react and be updated once a new Qt version is out. > > > with RC2, there is a new problem: > > > > /usr/bin/cmake -E cmake_progress_report > > kdebindings-1077263/build/CMakeFiles > > > > What is the solution here? > > You'll have to ask Richard Dale since this error is in smoke and not PyKDE. > > A strict ban on header file changes during the RC phase would be a good > way to help reduce these kinds of last minute problems. Even in these > late stages the plasma team are still stuffing around with their (new) > APIs. I don't think we need a strict ban. I think the problem is that the kde bindings release schedule is unavoidably slightly behind the KDE libraries release schedule. However, the overall KDE release schedule doesn't take this into account. 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. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
