Attempt to fixup dependency data declarations for non-KDE modules
ClosedPublic

Authored by ouwerkerk on Apr 5 2019, 6:32 PM.

Details

Summary

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

Test Plan

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.
ouwerkerk requested review of this revision.Apr 5 2019, 6:32 PM
ouwerkerk created this revision.
ouwerkerk edited the test plan for this revision. (Show Details)Apr 5 2019, 6:40 PM

Would it be possible to have all the external items sitting in their own namespace?

Would it be possible to have all the external items sitting in their own namespace?

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.

Would it be possible to have all the external items sitting in their own namespace?

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 ?

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.

ouwerkerk updated this revision to Diff 56128.Apr 13 2019, 12:04 PM
ouwerkerk edited the test plan for this revision. (Show Details)

Introduce the third-party/ prefix like bcooksley requested

ouwerkerk updated this revision to Diff 56129.Apr 13 2019, 12:06 PM

Fixup for search & replace breakage.

ouwerkerk updated this revision to Diff 56130.Apr 13 2019, 12:07 PM

Fixup for gpgme -> third-party/gpgme

ouwerkerk updated this revision to Diff 56132.Apr 13 2019, 12:09 PM

Fixup search & replace breakage.

@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...

ouwerkerk added a comment.EditedApr 17 2019, 7:59 PM

This looks fine to me, subject to being okayed by @mpyne

Only thing I do see is Qt5 being changed to third-party/Qt5

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)

mpyne accepted this revision.Apr 20 2019, 6:05 PM

I like the change! We'll need to watch for things to add to ignored-projects as @bcooksley points out.

This revision is now accepted and ready to land.Apr 20 2019, 6:05 PM
This revision was automatically updated to reflect the committed changes.