KDE Core/Platform 11/DownstreamConsiderations: Difference between revisions

From KDE Community Wiki
(Created page with 'Who are the downstreams? * Distros * 3rd party developers * Application developers Communications * release-team@ * kde-packagers@ * kde-devel@ for 3rd party developers. We ar...')
 
No edit summary
 
Line 1: Line 1:
{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
Who are the downstreams?
Who are the downstreams?
* Distros
* Distros

Latest revision as of 16:34, 6 June 2011

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


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