KDE Core/Platform 11/DownstreamConsiderations
< KDE Core | Platform 11
Who are the downstreams?
- Distros
- 3rd party developers
- Application developers
Communications
- release-team@
- kde-packagers@
- kde-devel@ for 3rd party developers.
We are not going to weaken existing rules for kdelibs
- Keep BC
- ... etc
- KDE libs rules apply to KDE frameworks.
- Modules need to maintain sonames for splits.
- This is out of scope for platform 11 in general, but we consider it as it is relevant
- Splits affect slackware in bad way, but other distros like the splits.
- Developers are also affected by the splits. Makes building more tedious.
- We can produce both monolithic and split tarballs for distros.
- We should split, but do it like ripping off a plaster. Quickly and one time.
Alex' CMake solution.
- Solves many problem
- Requires specifying dependencies in the superbuild file
- Individual parts are built and installed modularly one at a time.
- The file itself could potentially be generated by CMake by looking at the dependencies in the parts.
- FooConfig.cmake files might help by providing exported targets to import.
- Potentially causes efforts on behalf of build system maintainers of individual framework to be aware of possibility it will be part of a superbuild.
- Requires some CMake
- RPath issues (potentially) - distros don't use RPath. Developers will probably be able to handle it.
- Getting the sources from tags in branches.
- Slackware++ - a single package of libs and base runtime workspace and apps.
- Tool is relatively new - May have issues.
- Check changing generated directory structure inside the tarball so that it is not:
- prefix/libkipi/src
- prefix/libkipi/build
- prefix/libexiv/src
- prefix/libexiv/build
- ... etc
but
- prefix/src/CMakeLists (src otherwise not touched)
- prefix/build/src/libkipi
- prefix/build/src/libexiv
- prefix/build/build/libkipi
- prefix/build/build/libexiv
- Start candidates are graphics and edu
- ABI compliance checker tool
- Used already in phonon