attempt to fix dependency data declarations to help kdesrc-build sort the modules in the correct order.
See also: kdesrc-build issue 26 at invent.kde.org: https://invent.kde.org/kde/kdesrc-build/issues/26
Details
- Use the version of kdesrc-build from MR 7: https://invent.kde.org/kde/kdesrc-build/merge_requests/7
- Run kdesrc-build --list-build and check the output
Diff Detail
- Repository
- R499 Metadata for build scripts
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Do you mean having a separate dependency data file for them (e.g. dependency-data-external-kf5-qt5) ? Or do you mean having a distinct path so a module like taglib becomes e.g. external/taglib ?
If you mean the first thing, then that is certainly possible: kdesrc-build would need to make sure that other file gets read. We already have a separate dependency-data-common for instance. On the other hand some of these missing declarations like the dependencies on grantlee or taglib or gpgme are really just fixing *missing* entries in dependency-data-kf5-qt5.
If you mean the second: that would need a restructure of how kdesrc-build deals with these external modules: AFAIK it only supports that kind of structuring for KDE modules. I guess it would need a custom ModuleSet and/or additional entries in the sysadmin/repo-metadata repository or a dedicated equivalent for non-KDE modules if you don't want to add entries for them there.
I was referring to a distinct path.
If you mean the first thing, then that is certainly possible: kdesrc-build would need to make sure that other file gets read. We already have a separate dependency-data-common for instance. On the other hand some of these missing declarations like the dependencies on grantlee or taglib or gpgme are really just fixing *missing* entries in dependency-data-kf5-qt5.
Adding entries to dependency-data-kf5-qt5 is fine with me.
If you mean the second: that would need a restructure of how kdesrc-build deals with these external modules: AFAIK it only supports that kind of structuring for KDE modules. I guess it would need a custom ModuleSet and/or additional entries in the sysadmin/repo-metadata repository or a dedicated equivalent for non-KDE modules if you don't want to add entries for them there.
Unfortunately additional entries in sysadmin/repo-metadata isn't possible, because the data there is used by tooling which directly supports git.kde.org.
@bcooksley is this more to your liking now? I used the third-party/ prefix to mark non KDE modules.
This looks fine to me, subject to being okayed by @mpyne
Only thing I do see is Qt5 being changed to third-party/Qt5 - I believe both CI and kdesrc-build will have special case code for this name which we may need to adapt...
Yes, because Qt5 is a "third party" module...
- I believe both CI and kdesrc-build will have special case code for this name which we may need to adapt...
This works fine with kdesrc-build, because ultimately kdesrc-build only cares for the leaf "name" not the full path. (That also means you can't have two distinct modules using the same "name" under different paths, kdesrc-build can't cope with that. E.g. third-party/foo and kde/foo should not coexist.)
Okay. We'll need to make sure local-metadata/ignored-projects in sysadmin/ci-tooling is updated at the same time as i'm not sure if the CI tooling is as tolerant when ignoring projects (it certainly is when it comes to resolving the dependency graph)
I like the change! We'll need to watch for things to add to ignored-projects as @bcooksley points out.