| Summary: | dev-build/autoconf-archive-2021.02.19 - broken Qt5 detection using AX_HAVE_QT macro | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fab <netbox253> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | asturm, ionen, qt |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=863395 https://bugs.gentoo.org/show_bug.cgi?id=877477 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 544108 | ||
| Attachments: | error running latest upstream macro | ||
|
Description
Fab
2022-06-11 10:15:50 UTC
Please give an example project we can look at this with. But this sounds a lot like it's actually to do with the Qt bindir changes (see news). (In reply to Sam James from comment #1) > Please give an example project we can look at this with. But this sounds a > lot like it's actually to do with the Qt bindir changes (see news). Oh, sorry, I get your point, it should know about our locations. Duh. Given qmake5 is in PATH now, easiest would be s/qmake/qmake5/ and no need to worry about hardcoding paths or qmake-utils eclass. (In reply to Ionen Wolkens from comment #3) > Given qmake5 is in PATH now, easiest would be s/qmake/qmake5/ and no need to > worry about hardcoding paths or qmake-utils eclass. (also I did suggest on the qt6 PR that qt6 should get qmake6 there too, didn't last I checked) (In reply to Sam James from comment #2) > (In reply to Sam James from comment #1) > > Please give an example project we can look at this with. But this sounds a > > lot like it's actually to do with the Qt bindir changes (see news). > > Oh, sorry, I get your point, it should know about our locations. Duh. Yes. I'm developing a software on gentoo, and I'm using this macro to detect and setup Qt. Until now I haven't had to do any special stuff neither in my build system nor in an ebuild to make it work. Today I searched packages in the portage tree to see how things work for other packages, and I noticed that every ebuild/package I saw is doing some hacky things to make it work. On sys-libs/gwenhywfar : > > use qt5 && myeconfargs+=( > --with-qt5-moc="$(qt5_get_bindir)/moc" > --with-qt5-qmake="$(qt5_get_bindir)/qmake" > ) > > --with-qt5-{moc,qmake} options are coming from an old-custom version¹ of this macro, and now the developers of this package must patch this old version to fix bugs². On app-crypt/pinentry : > src_configure() { > export QTLIB="$(qt5_get_libdir)" > > econf \ > ... > MOC="$(qt5_get_bindir)"/moc \ > ... But... calling AX_HAVE_QT should just work. And it worked for me until now. Developing a package on gentoo does not mean that every build is done by emerge. Most of the time I'm doing the eternal configure-make on command line. Since upstream macro was patched for openSUSE, and since qt6 is coming, would it be possible to fix this once for all and for everyone ? 1. https://github.com/aqbanking/gwenhywfar/commit/11b63e8a7e5f2dc949de3bec0983de0e0255c75b 2. https://github.com/aqbanking/gwenhywfar/commit/b953672c5f668c2ed3960607e6e25651a2cc98db The difference is that qtchooser is not installed by default anymore and is intended for people that develop with qt directly rather than make ebuilds for it, so direct qmake doesn't get installed. https://www.gentoo.org/support/news-items/2022-03-30-qt-5_15_3-bump.html So in a way could actually say that this is not necessarily a bug (albeit checking qmake5/qmake6 may be useful), ebuilds should do their things, and developers install qtchooser. Created attachment 784652 [details] error running latest upstream macro I'm trying to use latest version of upstream ax_have_qt.m4 macro with AC_CHECK_PROGS patched like following : > AC_CHECK_PROGS(am_have_qt_qmexe,qmake qmake-qt6 qmake-qt5 qmake6 qmake5,[]) I thought this would work, but calling the macro failed. The config.log error is attached. As you can see in the attached file, the > QT_UIC= > QT_MOC= > QT_RCC= > QT_LRELEASE= > QT_LUPDATE= exported variables are empty, because which does not find them in PATH. In the qtcore ebuild¹, in install phase, we can find : > qt5_symlink_binary_to_path qmake 5 A symlink is done for qmake, but not for others utilities. This leads to the macro failure. 1. https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qtcore/qtcore-5.15.4-r2.ebuild#n104 (In reply to Fab from comment #7) > A symlink is done for qmake, but not for others utilities. > This leads to the macro failure. > > 1. > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qtcore/qtcore-5.15.4- > r2.ebuild#n104 This is by design and mimics what is provided as "user facing" by Qt6. I assume that revdeps could rely on this, so package should be fixed in a universal, non-Gentoo-specific way (taking into account '5' and 'qt5' prefixes or injecting one QTBINDIR path for all these tools, but the latter again relies on knowledge of having to do this in revdep packages). Nevertheless, as has been told, if you develop with Qt and rely on unversioned links to these Qt binaries in PATH, dev-qt/qtchooser as a tool still works for you with direct control over the (main) version you want. In the past, Qt packages in Gentoo were using it as a means to switch the 'default' Qt implementation, and you as a developer would not have had control over when the switch from Qt4 to Qt5 happened, and had we gone forward with it, the switch to Qt6 as well. Fixing assignee. (In reply to Andreas Sturmlechner from comment #8) > (In reply to Fab from comment #7) > (taking into account '5' and 'qt5' prefixes... *suffixes (In reply to Andreas Sturmlechner from comment #8) > Nevertheless, as has been told, if you develop with Qt and rely on > unversioned links to these Qt binaries in PATH, dev-qt/qtchooser as a tool > still works for you with direct control over the (main) version you want. The problem is that, I, as developer, do not need these tools. As a developer, I'm using only the AX_HAVE_QT macro provided by the sys-devel/autoconf-archive gentoo package. The macro needs these tools to check the Qt correct installation, I do not. Yes. But you can still use dev-qt/qtchooser to resolve the situation for you *right now*. Yes, that's true, thank you, I understood it well. This also means that I must add an *unneeded dependency* to my ebuild until this bug is resolved. Do you see why I'm unwilling ? If half of the macros distributed by autoconf-archive package does not work on the system where they are installed, or require extras deps to run, then it is useless to provide such a package. I did not opened this bug to bother any of you, and I do not ask you to fix this *right now*. I simply think this is a real problem, especially on a OS where you build everything from sources, and where often we are asked to report problems upstream. (In reply to Fab from comment #12) > Yes, that's true, thank you, I understood it well. > This also means that I must add an *unneeded dependency* to my ebuild until > this bug is resolved. Do you see why I'm unwilling ? C'mon, it is half a meg of mostly symlinks you had unconditionally installed until 5.15.3 anyway. (In reply to Andreas Sturmlechner from comment #13) > C'mon, it is half a meg of mostly symlinks you had unconditionally installed > until 5.15.3 anyway. That's not the problem, but okay. Let's go, let's start doing anything with dependencies in the portage tree. Did you somehow skip over this? (In reply to Andreas Sturmlechner from comment #8) > I assume that revdeps could rely on this, so package should be fixed in a > universal, non-Gentoo-specific way I'm not talking you out of this bug. asturm was pretty much just explaining why it's not a "qt@" problem and why it's a bug in the macros if anything. And that as a workaround, the dep on qtchooser isn't horrible for now, if you must. I think you've misinterpreted. It is indeed an issue in the macros which should be fixed. (In reply to Andreas Sturmlechner from comment #8) > I assume that revdeps could rely on this, so package should be fixed in a > universal, non-Gentoo-specific way (taking into account '5' and 'qt5' > prefixes +1 Package has more issues, see `which` bug. Since sci-libs/silo has simply copied that part of the macro, linking my hacking of QT_BIN_DIR into it here as well: https://github.com/gentoo/gentoo/blob/2ec5dd82dd63f265822a2e4e37aabc722d1bcac0/sci-libs/silo/files/silo-4.11-qtbindir.patch Debian are patching it as well: https://salsa.debian.org/debian/autoconf-archive/-/blob/master/debian/patches/0001-Fix-AX_HAVE_QT.patch *** Bug 881175 has been marked as a duplicate of this bug. *** (In reply to Andreas Sturmlechner from comment #19) > Debian are patching it as well: > > https://salsa.debian.org/debian/autoconf-archive/-/blob/master/debian/ > patches/0001-Fix-AX_HAVE_QT.patch This lands in https://github.com/autoconf-archive/autoconf-archive/commit/a6c0e47e237215228d4af0abfbd18cf2ad8b3fd7 (2023.02.20). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92d13a6c5aee33c11fcfcb71adda551ffd79626f commit 92d13a6c5aee33c11fcfcb71adda551ffd79626f Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-20 23:33:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-20 23:33:20 +0000 sys-devel/autoconf-archive: add 2023.02.20 Bug: https://bugs.gentoo.org/851195 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/autoconf-archive/Manifest | 1 + .../autoconf-archive-2023.02.20.ebuild | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+) |
