Mentioned that in the qt6 PR before, but filing here so it's not forgotten. It exists in the ::qt overlay wrt $url but both eclasses are out of sync and missing changes that exists in one but not the other. Not urgent given currently using a ugly hack that s/qt5/qt6/ on $(qt5_get_bindir)/qmake, but I'd like to replace by either $(qt6_get_bindir)/qmake or $(type -P qmake6) which would work if it existed in PATH like /usr/bin/qmake5 does (calling qmake6 is all I need really, well I also use qt5_get_qmake_args but it works just fine with qt6 as-is).
IIRC there should definitely be a qmake6 binary in PATH, you shouldn't need to use qt6_get_bindir for that. If it's not there, we're missing something in our packaging (or upstream changed things again). That being said, there are lots of "broken" build system that need to invoke other tools (e.g., moc) directly and do not (or cannot) rely on qmake or cmake for autodetection, so we'll probably still need qt6_get_bindir & friends in qmake-utils.eclass as a workaround.
(In reply to Davide Pesavento from comment #1) > IIRC there should definitely be a qmake6 binary in PATH, you shouldn't need > to use qt6_get_bindir for that. If it's not there, we're missing something > in our packaging (or upstream changed things again). It's not, otherwise I'd have used that already. qtcore:5 manually does the symlink (qt5_symlink_binary_to_path qmake 5) and that was done after the qt6 ebuilds were made and seems never carried over. > That being said, there are lots of "broken" build system that need to invoke > other tools (e.g., moc) directly and do not (or cannot) rely on qmake or > cmake for autodetection, so we'll probably still need qt6_get_bindir & > friends in qmake-utils.eclass as a workaround. Yeah, there was also bug #851195 as you know. Albeit moc is currently not in the same directory for qt6, likely full on intend on "don't call this yourself" wrt libexec. $ qfile -v moc qmake dev-qt/qtbase-6.3.1: /usr/lib64/qt6/bin/qmake dev-qt/qtbase-6.3.1: /usr/lib64/qt6/libexec/moc dev-qt/qtcore-5.15.5-r2: /usr/lib64/qt5/bin/moc dev-qt/qtcore-5.15.5-r2: /usr/lib64/qt5/bin/qmake
Oh and qmake6 does exist, but it's stuck in there too: $ qfile -v qmake6 qmake5 dev-qt/qtbase-6.3.1: /usr/lib64/qt6/bin/qmake6 dev-qt/qtcore-5.15.5-r2: /usr/bin/qmake5 -> ../lib64/qt5/bin/qmake
(In reply to Ionen Wolkens from comment #2) > Yeah, there was also bug #851195 as you know. Albeit moc is currently not in > the same directory for qt6, likely full on intend on "don't call this > yourself" wrt libexec. Yep, that's idea. Upstream doesn't consider moc a "user facing" tool and as such it should not be invoked manually by the user and does not need to be in PATH.
(In reply to Ionen Wolkens from comment #3) > Oh and qmake6 does exist, but it's stuck in there too: > > $ qfile -v qmake6 qmake5 > dev-qt/qtbase-6.3.1: /usr/lib64/qt6/bin/qmake6 > dev-qt/qtcore-5.15.5-r2: /usr/bin/qmake5 -> ../lib64/qt5/bin/qmake Yeah I think we need to create the versioned symlink ourselves, i.e.: /usr/bin/qmake6 -> /usr/lib64/qt6/bin/qmake I'm not sure why /usr/lib64/qt6/bin/qmake6 exists though. It should not have the "6" suffix.
(In reply to Davide Pesavento from comment #5) > I'm not sure why /usr/lib64/qt6/bin/qmake6 exists though. It should not have > the "6" suffix. Both qmake and qmake6 exist and are the same file $ md5sum /usr/lib64/qt6/bin/qmake* 4fbeb74ea6eb97a1e80a1abbf40d71c2 /usr/lib64/qt6/bin/qmake 4fbeb74ea6eb97a1e80a1abbf40d71c2 /usr/lib64/qt6/bin/qmake6 My impression is that qmake6 is just being installed in the wrong directory. full list of what's in there for me: $ ls -1 /usr/lib64/qt6/bin qdbuscpp2xml qdbusxml2cpp qmake qmake6 qml qmldom qmleasing qmlformat qmllint qmlplugindump qmlpreview qmlprofiler qmlscene qmltc qmltestrunner qmltime qsb qt-cmake qt-cmake-private qt-cmake-private-install.cmake # eh.. qt-cmake-standalone-test qt-configure-module qtpaths qtpaths6
(In reply to Ionen Wolkens from comment #6) > (In reply to Davide Pesavento from comment #5) > > I'm not sure why /usr/lib64/qt6/bin/qmake6 exists though. It should not have > > the "6" suffix. > Both qmake and qmake6 exist and are the same file > > $ md5sum /usr/lib64/qt6/bin/qmake* > 4fbeb74ea6eb97a1e80a1abbf40d71c2 /usr/lib64/qt6/bin/qmake > 4fbeb74ea6eb97a1e80a1abbf40d71c2 /usr/lib64/qt6/bin/qmake6 Ok, and is qmake6 a hardlink? > > My impression is that qmake6 is just being installed in the wrong directory. I don't think so. The qmake build target specifies INSTALL_VERSIONED_LINK, which ends up calling qt_internal_install_versioned_link [1]. That cmake code looks like an unreadable mess to me, but it seems that both 'original' and 'linkname' use the same base path, so they're supposed to be in the same directory. [1] https://github.com/qt/qtbase/blob/fb1b20eab30096f3f9edf3da1200fbe8e2f66b2c/cmake/QtInstallHelpers.cmake#L103 AFAIK, and from what I remember from discussions on upstream's ML, the symlinks in /usr/bin are left entirely up to packagers, i.e. it's our responsibility to create them.
https://doc.qt.io/qt-6/packaging-recommendations.html
(In reply to Davide Pesavento from comment #7) > Ok, and is qmake6 a hardlink? Just looked and yep. > AFAIK, and from what I remember from discussions on upstream's ML, the > symlinks in /usr/bin are left entirely up to packagers, i.e. it's our > responsibility to create them. > > https://doc.qt.io/qt-6/packaging-recommendations.html Thanks, that makes this clearer. Also tried that for qtbase, if add -DINSTALL_PUBLICBINDIR="${EPREFIX}"/usr/bin, I get a single line: $ cat "${BUILD_DIR}"/user_facing_tool_links.txt /usr/lib64/qt6/bin/qmake /usr/bin/qmake6 Anyhow, if the qtbase ebuild makes the symlink and I can use it, don't personally need anything new from qmake-utils then.
I'll go ahead and change this bug to this, maybe qmake-utils will need something later but should probably wait until it's actually needed by something.
I gave this a go using 'dosym', but I am very failing to understand how to use it it seems. I blame going too deep into SSH too long this week elsewhere, for way too long time per day...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=598ef1e2bb0fb3c13c58dfa4abff3869ff7534b9 commit 598ef1e2bb0fb3c13c58dfa4abff3869ff7534b9 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2022-10-16 13:23:40 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2022-10-16 13:35:17 +0000 dev-qt/qtbase: add 'dosym' for 'qmake' Also sort some of the configure variables. Bug: https://bugs.gentoo.org/863395 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> dev-qt/qtbase/qtbase-6.4.0.ebuild | 21 ++++++++++++++------- dev-qt/qtbase/qtbase-6.4.9999.ebuild | 21 ++++++++++++++------- dev-qt/qtbase/qtbase-6.9999.ebuild | 21 ++++++++++++++------- 3 files changed, 42 insertions(+), 21 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c2b15ca2f28c0decd82dff7167b73a455ac1c7b1 commit c2b15ca2f28c0decd82dff7167b73a455ac1c7b1 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2022-10-14 15:30:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-02 05:09:45 +0000 dev-qt/*: add version 6.4.0 Bug: https://bugs.gentoo.org/838970 Bug: https://bugs.gentoo.org/863224 Bug: https://bugs.gentoo.org/875956 Closes: https://bugs.gentoo.org/862525 Closes: https://bugs.gentoo.org/863395 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/27812 Signed-off-by: Sam James <sam@gentoo.org> dev-qt/qt5compat/Manifest | 1 + dev-qt/qt5compat/qt5compat-6.4.0.ebuild | 18 ++ dev-qt/qtbase/Manifest | 1 + dev-qt/qtbase/qtbase-6.4.0.ebuild | 185 ++++++++++++++++ dev-qt/qtcharts/Manifest | 1 + dev-qt/qtcharts/qtcharts-6.4.0.ebuild | 18 ++ dev-qt/qtdeclarative/Manifest | 1 + dev-qt/qtdeclarative/qtdeclarative-6.4.0.ebuild | 30 +++ dev-qt/qtimageformats/Manifest | 1 + dev-qt/qtimageformats/qtimageformats-6.4.0.ebuild | 35 +++ dev-qt/qtmultimedia/Manifest | 1 + dev-qt/qtmultimedia/qtmultimedia-6.4.0.ebuild | 42 ++++ dev-qt/qtnetworkauth/Manifest | 1 + dev-qt/qtnetworkauth/qtnetworkauth-6.4.0.ebuild | 17 ++ dev-qt/qtpositioning/Manifest | 1 + dev-qt/qtpositioning/qtpositioning-6.4.0.ebuild | 19 ++ dev-qt/qtquick3d/Manifest | 1 + dev-qt/qtquick3d/qtquick3d-6.4.0.ebuild | 32 +++ dev-qt/qtquicktimeline/Manifest | 1 + .../qtquicktimeline/qtquicktimeline-6.4.0.ebuild | 18 ++ dev-qt/qtserialport/Manifest | 1 + dev-qt/qtserialport/qtserialport-6.4.0.ebuild | 18 ++ dev-qt/qtshadertools/Manifest | 1 + dev-qt/qtshadertools/qtshadertools-6.4.0.ebuild | 17 ++ dev-qt/qtsvg/Manifest | 1 + dev-qt/qtsvg/qtsvg-6.4.0.ebuild | 18 ++ dev-qt/qttools/Manifest | 1 + .../files/qttools-6.4.0-clang-15-build.patch | 73 ++++++ dev-qt/qttools/qttools-6.4.0.ebuild | 55 +++++ dev-qt/qtwayland/Manifest | 1 + dev-qt/qtwayland/qtwayland-6.4.0.ebuild | 22 ++ dev-qt/qtwebchannel/Manifest | 1 + dev-qt/qtwebchannel/qtwebchannel-6.4.0.ebuild | 19 ++ dev-qt/qtwebengine/Manifest | 1 + .../qtwebengine-6.4.0-no-websocket-intercept.patch | 38 ++++ dev-qt/qtwebengine/qtwebengine-6.4.0.ebuild | 245 +++++++++++++++++++++ dev-qt/qtwebsockets/Manifest | 1 + dev-qt/qtwebsockets/qtwebsockets-6.4.0.ebuild | 18 ++ 38 files changed, 955 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea3d847a8b9e50f49b0f3a8fcf24e0e67f2298c3 commit ea3d847a8b9e50f49b0f3a8fcf24e0e67f2298c3 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-26 20:40:44 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-05 13:01:09 +0000 qt6-build.eclass: use upstream intended user_facing_tool_links.txt Primary goal is to reduce the amount of things we need to track, both what to install and when the symlink needs to be created based on USE. Without this, a module could introduce a new tool and may not even notice that it needs a symlink. Essentially replaces qt6_symlink_binary_to_path which I do not believe will have further uses (thus marking deprecated). That is, unless we want to diverge from upstream intended links, but even then may as well use a normal dosym in ebuilds. Also re-arrange mycmakeargs a bit because yet again qttranslations is the odd one out. Bug: https://bugs.gentoo.org/863395 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 46 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 42 insertions(+), 4 deletions(-)