On Sat, Apr 16, 2016 at 3:20 AM, Eric Hameleers <al...@slackware.com> wrote: > On Fri, 15 Apr 2016, Martin Graesslin wrote: > >>>>> Please understand this. >>>>> As a distro packager, I would welcome a simple piece of documentation >>>>> written by the developer that is *not* a CMakeLists.txt file. >>>> >>>> >>>> At Plasma we are currently discussing a metadata format for our projects >>>> including the inter-project dependencies. Please have a look at https:// >>>> mail.kde.org/pipermail/plasma-devel/2016-April/051581.html whether that >>>> would help you. >>> >>> >>> Inter-project dependencies need to be stored in a central repository. >>> Otherwise it is *impossible* for scripts such as kdesrc-build as well >>> as the CI system to resolve project dependencies (because you need to >>> drag in dependencies of dependencies). >>> This issue is actually more severe for kdesrc-build which needs to be >>> able to resolve the dependency tree to determine the build order. >>> >>> Please consult with those of us who have worked on inter-project >>> dependency stuff within KDE before when making proposals such as this. >> >> >> Please note that this does not intend to replace the global dependency >> data. >> It's more intended to be of use for distributions. I completely understand >> Eric's concerns and are trying to address exactly that. >> >> The main problem with the more global build data is that it's rolling. It >> doesn't preserve the dependencies. E.g. if I would look at build metadata >> for >> KWin right now it would not match the dependencies of the Plasma 5.6 >> releases. >> >> As the metadata is bundled with the tarball it would be up to date. >> >> Cheers >> Martin > > > I understand that the CI tools need to be able to resolve interdependencies. > So, why not use CI functionality to generate a global dependency list and > publish that? It would be an essential first stop for everyone trying to > compile KDE components.
If you clone the repository kde-build-metadata from git.kde.org you will find in the tools folder a script called "list_dependencies". Once given a branch group (usually kf5-qt5, but for Qt 4 based software you'll want to use latest-qt4) and the name of the repository it can spit out the complete list of projects a given tarball / repository depends on. Additional work would be needed to sort this into a build order, but for those of you whose packaging systems just need to know what to depend on, that should be quite helpful I think. > > But Martin's proposal is a sane one, too. If a project documents internally, > in its own release tarballs, in an agreed-upon file format, which other KDE > components it is relying on, that would be helpful indeed for distro > packagers. The CI tools will probably only look at git head and not bother > with releases (correct me if I am wrong). But the developer will have to > keep a dependency list (obscure and not easily readable to human eyes) in > CMakeLists anyway, so doing the same in a human-readable way is a bonus for > us, humans. > > Cheers, Eric Regards, Ben > > -- > Eric Hameleers <al...@slackware.com> > Home: http://alien.slackbook.org/blog/ > _______________________________________________ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team