Allow building sddm-greeter for both Qt 5 and Qt 6 in one go

[Vogtinator]

With #1789 it's possible to have sddm-greeter and sddm-greeter-qt6 on the same system, but this requires building all of SDDM twice. With this PR, a Qt 6 build also installs a Qt 5 greeter automatically and the other way is also possible, but optional.

• This depends on Provide coinstallability for Qt 5 and Qt 6 themes #1789
• Should the components and data/translations folders be moved into src/greeter? That way the ugly use of PARENT_SCOPE could be avoided, but it mixes data and QML with C++ code.
• Do the new BUILD_GREETER_QTX options make sense?
• Should the CI build the Qt 5 SDDM + Qt 6 greeter scenario as well?
• This probably needs a newer CMake minimum version. Find out which exactly (probably 3.25 for block()?) and check whether that's acceptable.

[davidedmundson]

There's a discussion about the translations in the other MR, but I'll press the approve button here to show I read through all 3 commits.

Code is fine for what it's doing.

I don't think it's something we want to support forever, it might be easy enough to add support now, but it can end up holding back development and is the sort of thing that can break silently when someone modernises the SDDM components.

[Vogtinator]

There's a discussion about the translations in the other MR, but I'll press the approve button here to show I read through all 3 commits.

Code is fine for what it's doing.

I don't think it's something we want to support forever, it might be easy enough to add support now, but it can end up holding back development and is the sort of thing that can break silently when someone modernises the SDDM components.

Yes. The question is how long we want to keep Qt 5 support (at least for the greeter). IMO as long as it doesn't hold back progress to an unreasonable extent we should keep it, which could be longer than we might expect now.

This PR itself is mostly to make building + packaging easier, but it's not technically necessary.

[davidedmundson]

This depends on
#1789

Should the components and data/translations folders be moved into src/greeter? That way the ugly use of PARENT_SCOPE could be avoided, but it mixes data and QML with C++ code.

There's nothing wrong with mixing QML and C++, they're both code. Mixing big wallpapers not so much

Do the new BUILD_GREETER_QTX options make sense?

If we're going to go down this route, yes.

Should the CI build the Qt 5 SDDM + Qt 6 greeter scenario as well?

Ideally.

This probably needs a newer CMake minimum version. Find out which exactly (probably 3.25 for block()?) and check whether that's acceptable.

Anything that's approved for use in other projects (such as Plasma)

There's a discussion about the translations in the other MR, but I'll press the approve button here to show I read through all 3 commits.
Code is fine for what it's doing.
I don't think it's something we want to support forever, it might be easy enough to add support now, but it can end up holding back development and is the sort of thing that can break silently when someone modernises the SDDM components.

Yes. The question is how long we want to keep Qt 5 support (at least for the greeter). IMO as long as it doesn't hold back progress to an unreasonable extent we should keep it, which could be longer than we might expect now.

This PR itself is mostly to make building + packaging easier, but it's not technically necessary.

Yeah, it's definitely one of those "person who actually does the work decides" situations, so could go any way.

🚢

[evelikov]

Out of curiosity: are there other KDE projects that allow building against both Qt5 and Qt6 in one go?

Glancing through some Arch packages kdsoap for example, the build is done twice. Perhaps that's was a deliberate package maintainer decision?

[Vogtinator]

Out of curiosity: are there other KDE projects that allow building against both Qt5 and Qt6 in one go?

Yes: breeze, oxygen, plasma-integration and phonon(-vlc) at least.