[qtbase] Fix PACKAGE_PREFIX_DIR substitution, which was broken by CMake 3.29.1

[fwcd]

This substitution no longer works due to upstream changes in CMake, which changes the PACKAGE_PREFIX_DIR variable to a non-fixed name. Strangely I only ran into this issue while building an older vendored version of Qt submodule ports (see e.g. this build), but we should update this code anyway.

Checklist

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[fwcd]

Since Qt generates the use of PACKAGE_PREFIX_DIR in Qt6CoreToolsAdditionalTargetInfo.cmake, this is an upstream issue too:

• https://bugreports.qt.io/browse/QTBUG-124186
• https://codereview.qt-project.org/c/qt/qtbase/+/553537

[dg0yt]

Duplicates #38017. Issue tracked in #37968.

[fwcd]

The PR you linked fixes vcpkg-cmake-config, not qtbase, that's a different port

[dg0yt]

So this complements the other PR.
FTR re2 also needs a specific fix due to this variable.

[Neumann-A]

close. Upstream CMake reverted the change

[fwcd]

Maybe this patch would be a good idea regardless, to make the substituion robust against other variable names? Especially if Qt moves forward with their patch (regardless of what CMake is doing)

[JavierMatosD]

Closing since CMake reverted the change. Since CMake is going to pursue a different solution for this problem, we shouldn't do this and we should support the new solution.

[fwcd]

Did Qt also revert the change? I haven't checked, but if not, this is going to bite us on the next port update.

[Neumann-A]

I think this string replacement no longer applies any way and could be removed in future updates