[qtkeychain] switch to Qt6; add qtkeychain-qt5; update to 0.13.1

[Be-ing]

and update to 0.13.1

• What does your PR fix?

  Fixes qtkeychain unable to build with Qt6. Also add libsecret dependency on Linux.

• Which triplets are supported/not supported? Have you updated the CI baseline?

  all

• Does your PR follow the maintainer guide?

  yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  yes

[Be-ing]

Originally I planned to fail the port build if neither qt5 nor qt6 feature was selected and intentionally not select one by default because accidentally pulling in either could result in a big increase in build time. CI is not happy about this because CI doesn't pick either, so I guess one or the other needs to be picked as a default feature. I am leaning towards picking the newer one and leaving users who need to stay with Qt5 to explicitly opt to do so. However this could surprise users who are already using this port with Qt5. Thoughts?

[JackBoosY]

cc @Neumann-A for review this PR.

[cenit]

exclusive features are forbidden by policy (i know there exist some, but they were allowed before the policy was enforced)

[Be-ing]

What is the alternative then? Use separate packages for building QtKeychain with Qt5 or Qt6?

[Be-ing]

I got some curious errors building this with Qt6 on Windows:

-- Configuring done
CMake Error at C:/mixxx-vcpkg/installed/x64-windows/share/Qt6LinguistTools/Qt6LinguistToolsMacros.cmake:94 (add_custom_command):
  OUTPUT path

    C:/mixxx-vcpkg/buildtrees/qtkeychain/src/v0.12.0-c92b7c53b3.clean/translations/qtkeychain_de.ts

  in a source directory as an output of custom command.
Call Stack (most recent call first):
  CMakeLists.txt:111 (qt6_create_translation)
  CMakeLists.txt:210 (qt_create_translation)


CMake Error at C:/mixxx-vcpkg/installed/x64-windows/share/Qt6LinguistTools/Qt6LinguistToolsMacros.cmake:94 (add_custom_command):
  OUTPUT path

    C:/mixxx-vcpkg/buildtrees/qtkeychain/src/v0.12.0-c92b7c53b3.clean/translations/qtkeychain_fr.ts

  in a source directory as an output of custom command.
Call Stack (most recent call first):
  CMakeLists.txt:111 (qt6_create_translation)
  CMakeLists.txt:210 (qt_create_translation)


CMake Error at C:/mixxx-vcpkg/installed/x64-windows/share/Qt6LinguistTools/Qt6LinguistToolsMacros.cmake:94 (add_custom_command):
  OUTPUT path

    C:/mixxx-vcpkg/buildtrees/qtkeychain/src/v0.12.0-c92b7c53b3.clean/translations/qtkeychain_ro.ts

  in a source directory as an output of custom command.
Call Stack (most recent call first):
  CMakeLists.txt:111 (qt6_create_translation)
  CMakeLists.txt:210 (qt_create_translation)


CMake Error at C:/mixxx-vcpkg/installed/x64-windows/share/Qt6LinguistTools/Qt6LinguistToolsMacros.cmake:94 (add_custom_command):
  OUTPUT path

    C:/mixxx-vcpkg/buildtrees/qtkeychain/src/v0.12.0-c92b7c53b3.clean/translations/qtkeychain_ru.ts

  in a source directory as an output of custom command.
Call Stack (most recent call first):
  CMakeLists.txt:111 (qt6_create_translation)
  CMakeLists.txt:210 (qt_create_translation)


CMake Error at C:/mixxx-vcpkg/installed/x64-windows/share/Qt6LinguistTools/Qt6LinguistToolsMacros.cmake:94 (add_custom_command):
  OUTPUT path

    C:/mixxx-vcpkg/buildtrees/qtkeychain/src/v0.12.0-c92b7c53b3.clean/translations/qtkeychain_zh.ts

  in a source directory as an output of custom command.
Call Stack (most recent call first):
  CMakeLists.txt:111 (qt6_create_translation)
  CMakeLists.txt:210 (qt_create_translation)


-- Generating done
CMake Error:
  Running

   'C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe' '-C' 'C:/mixxx-vcpkg/buildtrees/qtkeychain/x64-windows-dbg' '-t' 'recompact'

  failed with:

   ninja: error: loading 'build.ninja': The system cannot find the file specified.

These errors occurred in this GitHub Actions job. The logs are available as a GitHub Actions artifact.

[cenit]

What is the alternative then? Use separate packages for building QtKeychain with Qt5 or Qt6?

yes, i think so

@BillyONeal @ras0219-msft

[Be-ing]

Ping @BillyONeal and @ras0219-msft, should the new package be for Qt5 or Qt6? I think it would make sense to keep the existing package with Qt5, but the generic qt packages have been switched to Qt6 so it could go either way. 🤷 I just need an answer to proceed.

[JackBoosY]

@Be-ing Please use qt6.

[Be-ing]

That does not answer my question. Which package name should use Qt6?

[JackBoosY]

That does not answer my question. Which package name should use Qt6?

According to our policy, we should not to add the conflict features, so please keep this port name since port qt is qt6 in the master branch.
The qt5 version should be named as qt5-keychain.

[Be-ing]

I think qt5-qtkeychain is a better package name because qtkeychain is not part of Qt.

[Be-ing]

On further thought, I think qtkeychain-qt5 is a better name to distinguish it from packages that are part of Qt.

[JackBoosY]

On further thought, I think qtkeychain-qt5 is a better name to distinguish it from packages that are part of Qt.

Accepted.

[Be-ing]

CI seems to be down for unrelated reasons.

[JackBoosY]

Will rerun this PR after #20730 merge.

[Be-ing]

x64-osx build for fontconfig failing seems unrelated??

"/usr/local/bin/meson", line 2
    PYTHONPATH="/usr/local/Cellar/meson/0.59.0/lib/python3.9/site-packages" exec "/usr/local/Cellar/meson/0.59.0/libexec/bin/meson"  "$@"
                                                                            ^
SyntaxError: invalid syntax

[cenit]

x64-osx build for fontconfig failing seems unrelated??

"/usr/local/bin/meson", line 2
    PYTHONPATH="/usr/local/Cellar/meson/0.59.0/lib/python3.9/site-packages" exec "/usr/local/Cellar/meson/0.59.0/libexec/bin/meson"  "$@"
                                                                            ^
SyntaxError: invalid syntax

same in other builds
#20658

[Be-ing]

Now both Qt5 and Qt6 Windows builds are failing to find Qt? Seems to be a problem with CI?

[Be-ing]

Well, this is weird. Since adding "host": true for the qttools dependency, CMake fails to find Qt6 on Windows. So I tried adding qtbase as a dependency without "host": true and now CMake finds Qt6 but then that brings back the error about not finding Qt Linguist. I have no idea what's going on.

[github-actions]

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout 356918c4c16c4ef67b6f869a852eb60bd438bcf6 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/q-/qtkeychain.json b/versions/q-/qtkeychain.json
index b6f6b59..d64613f 100644
--- a/versions/q-/qtkeychain.json
+++ b/versions/q-/qtkeychain.json
@@ -1,7 +1,7 @@
 {
   "versions": [
     {
-      "git-tree": "8362147ae2e80b848447dc2f88ad96965fe790c9",
+      "git-tree": "463e5f361e6d29d2ac477813e32872f63b6889c5",
       "version": "0.13.1",
       "port-version": 0
     },

[Be-ing]

CI is passing now skipping building translations for arm64-windows. I don't do any builds for arm64-windows and my users aren't asking for arm64-windows builds so I don't mind this. The libsecret build option is working for Linux. If anyone else wants to work on building qtkeychain for Qt6 with translated error messages on arm64-windows, go ahead, but I am tired of working on this one little PR and would like to move on.

[ras0219-msft]

Thanks @Be-ing for the work to make this happen and sorry that we haven't given it enough attention to push things through.

In contrast to @JackBoosY's suggestion at #20185 (comment), we absolutely should not pull the rug out from underneath existing users that expect qtkeychain to be based on qt5. In an extreme case, we could consider removing the name qtkeychain entirely and providing qtkeychain-qt5 and qtkeychain-qt6, but I don't see a compelling reason for this extreme.

Therefore, I've opened #21420 that cherry-picks the qtkeychain commit from this PR but swaps them (back to the original arrangement?).

Thanks once again; I hope we can get this merged soon.