Review Request 113723: Fix KIO to build standalone, prepare for moving into its tier
David Faure
faure at kde.org
Sat Nov 9 00:47:53 UTC 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113723/#review43285
-----------------------------------------------------------
staging/kio/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31176>
already listed 6 lines above
staging/kio/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31180>
Why? KDED doesn't provide a library.
staging/kio/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31175>
already listed 3 lines before.
staging/kio/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31181>
needed?
tier1/kcoreaddons/src/lib/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31179>
I agree about this one.
tier1/kcoreaddons/src/lib/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31178>
I think we should instead treat them as separate libs, and remove the inheritance from KCompositeJobPrivate in KIO::JobPrivate. It's just an optimization. We don't want to break BIC in an existing libkio if we ever change kcoreaddons' private classes.
(Unless we can guarantee that they are always the same version - like Qt does, but the difference is that they don't need to install private headers for this; and they have a runtime check for version mismatches).
All in all, I think an extra call to "new" per kio job is the simplest solution; a kio job takes much longer than that anyway.
tier3/kservice/src/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113723/#comment31177>
Why? My grepping for KServiceOffer says that it's only used in the kservice framework.
- David Faure
On Nov. 8, 2013, 5:01 p.m., Aleix Pol Gonzalez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113723/
> -----------------------------------------------------------
>
> (Updated Nov. 8, 2013, 5:01 p.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: kdelibs
>
>
> Description
> -------
>
> As you will see, this splitting was a bit harder than others:
> - KIO was using a couple of private headers from kjobwidgets, which now they will be installed.
> - The xslt_kde target was being used from KDocTools without having it exported. Now it will be properly exported.
> - Also defines all dependencies so it can be compiled independently, modularization is done as well.
>
>
> Diffs
> -----
>
> tier2/kdoctools/src/CMakeLists.txt 3940e98
> tier2/kdoctools/KDocToolsConfig.cmake.in PRE-CREATION
> tier2/kdoctools/KDocToolsConfig.cmake d501dc8
> tier2/kdoctools/CMakeLists.txt c2256ff
> superbuild/CMakeLists.txt 458fb4c
> tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c5
> staging/kio/tests/CMakeLists.txt 6cee291
> staging/kio/src/widgets/CMakeLists.txt d90386d
> staging/kio/src/ioslaves/http/tests/CMakeLists.txt 52c9f6c
> staging/kio/src/ioslaves/http/kcookiejar/CMakeLists.txt b0feff6
> staging/kio/src/ioslaves/help/CMakeLists.txt 40637dc
> staging/kio/src/filewidgets/CMakeLists.txt 31fe8c6
> staging/kio/CMakeLists.txt 6c7297e
> cmake/modules/FindGSSAPI.cmake
> cmake/modules/CMakeLists.txt 7910270
> tier3/kded/KDEDConfig.cmake.in 32f8d56
> tier3/kservice/src/CMakeLists.txt cc0c1a4
>
> Diff: http://git.reviewboard.kde.org/r/113723/diff/
>
>
> Testing
> -------
>
> Builds, Installs, tests still pass; both modularized and monolithic kdelibs.
>
>
> Thanks,
>
> Aleix Pol Gonzalez
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131109/b679d2dd/attachment.html>
More information about the Kde-frameworks-devel
mailing list