In T14164#253131, @dfaure wrote:

@skelly From what I understand, the problem with versionless targets is when they "leak" into generated FooConfig.cmake files, and then users can end up with bad mix-and-match.

I've found that one of the disadvantages of std::expected is that it causes the error type to appear in your API meaning it's

I forgot about it during the discussion yesterday, but the COMPATIBLE_INTERFACE_STRING and INTERFACE_QT_MAJOR_VERSION property are designed to prevent the accidental mixing

The proposal is to create unversioned KF:: targets in KF5 and in KF6 to be used for transition. The danger is that such targets get used permanently instead of just for transition. It might be better if such targets are created to use KFTransitional:: prefixed targets instead of KF::.

In T14164#250617, @vkrause wrote:

In T14164#250600, @dfaure wrote:

I'm wondering if this is really a good idea. Both for Qt and KF.

find_package(Qt 5 COMPONENTS Core) will happily pick up Qt5, Qt6 or Qt7, no? But that doesn't mean the code is ready for Qt6 or Qt7, so we don't want that for Qt5 code.

Finding and using targets are two separate issues though. You can continue to use find_package(Qt5 ...) but link against Qt::Core. The versionless targets still reduce the number of places that hardcode a major version considerably in that case.

My preference would be to use the ClangConfig.cmake instead of introducing these new files.

In D4509#85725, @shaheed wrote:

The PEP-8 changes are some blank line changes.

Is anything here actually a PEP 8 fix?

@arojas Is something comparable already done like that elsewhere in KDE? Like for documentation for example?

@arojas Does that imply that 'make' alone should not build the bindings? I don't think that's generally desirable.

It's true that QFlags has a ctor taking a nullptr. The bindings-related problem was in our handling of enums by prepending a namespace, so we would end up with Qt::nullptr. I've fixed that in ECM, and also fixed handling of = {} for various types too.

In D3987#78468, @dfaure wrote:

{} sounds like the best solution to me.

@sitter FYI

I added https://commits.kde.org/extra-cmake-modules/29b9db8d67c67d4d1303e8dd9804f698fbaefbe1 in an attempt to resolve the issue of multiple packages installing the same __init__.py file.

Update on the installation directory issue. Instead of using 'dist-packages', the default is now 'site-packages', and packagers can now customize the install location for a package by passing

Update on bug https://bugs.kde.org/show_bug.cgi?id=374801 , myself and @arojas fixed it. Packagers may want to cherry-pick the 8aa6843404f9c6faef66cb9c76358158eafc1af1 commit in ECM, and ed1b9ce2bb2a2e51410e0a1754a72c110010a6a0 if you encounter other problems to diagnose.

If anyone else here can reproduce the issue in https://bugs.kde.org/show_bug.cgi?id=374801 I would appreciate if you could dig into it and figure out what the problem is.

@arojas I raised that issue in June: http://comments.gmane.org/gmane.comp.kde.distributions/92 and it came up in November: https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg39376.html

Thanks for filing this.