Consider the kgoldrunner application. It depends on libkdegames, like most (all?) of the other games under kde/kdegames. It would make a lot of sense to include libkdegames as an implicit dependency of kgoldrunner, much as asking for kde/kdegames causes all modules under kde/kdegames to be pulled into the build. We can't simply include all dependencies of a module as you'd end up with insanity like trying to build Qt, soprano, kdelibs, etc. from master just to e.g. build kcalc. So there would need to be a good criteria for which modules to implicitly include. My current proposal is: If the module being built is a leaf node of the project database, then include any marked dependencies that have the same parent (i.e. any sibling dependencies).
I am interested in understanding and resolving this issue as I am interested in understanding how kdesrc-build works and would like to learn more. Could you please point to a starting point in this issue's resolution? Thanks a lot!
Hi Aasif! We recently had a new contributor add a new dependency resolver to kdesrc-build which also helps set the right conditions for treating non-KDE modules as dependencies. Please see the long thread at https://invent.kde.org/kde/kdesrc-build/merge_requests/6 as a starter. You might also look at https://invent.kde.org/kde/kdesrc-build/tree/master/doc/source-reference which has a little bit of detail on kdesrc-build internals. Depending on your waking hours I'm also sometimes available on Freenode IRC in #kde-devel as the user "mpyne". I'm typically there from 1900-2300 New York time during the work week and somewhat longer on weekends.
Each project has now .kde-ci.yml, in each kde game the dependency is listed. For example: kde/kdegames/kgoldrunner: kde/kdegames/libkdegames See https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/dependencies/dependency-data-kf6-qt6?ref_type=heads