Review Request 109503: Compile with current qt dev branch

[Stephen Kelly]

> On March 15, 2013, 5:07 p.m., Stephen Kelly wrote:
> > The problem is that build.kde.org uses qt5.git, which does not yet have that commit. Actually qt5.git hasn't been updated in 6 weeks: https://codereview.qt-project.org/#change,46445
> > 
> > If b.k.o can be updated to use the dev branches of the qt 5 submodules, I think that's a good idea. In general, I think it's a bad idea to use qt5.git or to recommend anyone else use it (as is currently recommended on the wiki).
> > 
> > At any rate, this patch shouldn't go in until b.k.o can build it.
> 
> Ben Cooksley wrote:
>     Easier said than done. build.kde.org uses a separate install prefix for each project it builds.
>     Somehow I suspect the Qt5 CMake system would shatter if it was asked to install each Qt5 submodule into it's own prefix.
>     
>     Not to mention that it would make updating Qt5 on build.kde.org a royal PITA because you would have to run the module builds in their precise upstream dependency order (in case of incompatibilites) which Jenkins isn't really designed for (from what I have seen in it's interface so far at least). It would also mean maintaining a list of their modules on build.kde.org.
>     
>     Is there any good reason why the Qt developers are dragging the chain and not updating qt5.git? Obviously the individual modules build fine...
> 
> David Faure wrote:
>     qt5.git is behind because of unstability of the Qt CI. This is being worked on, I don't think we should change anything on our side.
>     You can track progress at https://codereview.qt-project.org/46445
> 
> Albert Astals Cid wrote:
>     Ok, this means that our code is uncompilable if one follows the instructions on how to compile it, but i guess we are ok with that.
> 
> David Faure wrote:
>     This is a slight simplification of the problem... the instructions do say "use qt5.git". The other solution (use qtbase+qtsvg+qtx11extras only) is already documented as suboptimal (not enough for plasma-framework, which we should at least check compiles when making API changes in kdelibs).
>     
>     Fixed: added a note to the instructions ("git checkout 90361fd in qtbase").

Ben, would it be possible to run 

git submodule foreach 'git pull || true'

on qt5.git when updating it? That would isolate us from the need for qt5.git to get through the CI.


- Stephen


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109503/#review29284
-----------------------------------------------------------


On March 15, 2013, 8:42 p.m., Albert Astals Cid wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109503/
> -----------------------------------------------------------
> 
> (Updated March 15, 2013, 8:42 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> -------
> 
> 34a3f2cd442ff1396e508f7a8890b968f1bb3179 has been merged to qtbase and now frameworks contains definitions of functions that clash with the ones from Qt itself
> 
> 
> Diffs
> -----
> 
>   kdecore/tests/kdatetimetest.cpp d64492b 
>   libkdeqt5staging/src/CMakeLists.txt 6572b92 
>   libkdeqt5staging/src/qtest_staging.h c2b081e 
>   staging/kde4support/src/kdecore/qtest_kde.h 7174893 
> 
> Diff: http://git.reviewboard.kde.org/r/109503/diff/
> 
> 
> Testing
> -------
> 
> Compiles
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130316/b9a4b018/attachment.html>