Created attachment 446990 [details, diff] Add a qt5 USE flag Hi, I've added qt5 support to the latest gnuplot release ebuild.
Created attachment 446992 [details, diff] Add a qt5 USE flag - correction Replaced the patch, turns out qtnetwork:5 rather than qtsvg:5 is linked.
If qt4 has been optional before, then '^^ ( qt4 qt5 )' will force exactly one of them to be enabled all the time. So that does not seem right. If only one of qt4, qt5 is allowed to be enabled at the same time, that would be 'foo? ( !bar )' - but frankly, a lot of users are not able to solve the resulting blocker if both use flags are enabled. Considering that the time of qt4 is limited, I would recommend to get rid of the qt4 option in favor of qt5.
Created attachment 447236 [details, diff] Support building against qt5, remove qt4 dependency Good point on both counts, let's do it. Here's the patch to ditch qt4 altogether. Not too happy about the line to stop gnuplot to link against Qt automatically if found: $(if ! use qt5; then echo '--with-qt=no'; fi) maybe somebody can express it more elegantly.
There is no need in $(if ! use qt5; then echo '--with-qt=no'; fi), because --without-qt is the same as --with-qt=no.
ping
The ebuild also contains these lines: if use prefix && use qt4; then append-ldflags -Wl,-rpath,"${EPREFIX}"/usr/$(get_libdir)/qt4 fi Is a similar workaround needed for qt5, or does it build on prefix without this? CCing prefix.
It appears to me we don't have qt5 keyworded for prefix, do we? That said, I think it's ok to drop qt4 support for prefix, I'm not aware of a usecase for it right now.
(In reply to Fabian Groffen from comment #7) > It appears to me we don't have qt5 keyworded for prefix, do we? That said, > I think it's ok to drop qt4 support for prefix, I'm not aware of a usecase > for it right now. Thanks for the quick reply. We are going to drop qt4 support in 5.0.7 and in the 5.2* series then. (In reply to Andreas Eckstein from comment #1) > Replaced the patch, turns out qtnetwork:5 rather than qtsvg:5 is linked. qtsvg is needed too, though. I see all of the following (with scanelf -n): /usr/bin/gnuplot: libQt5Network.so.5, libQt5Gui.so.5, libQt5Core.so.5 /usr/libexec/gnuplot/5.0/gnuplot_qt: libQt5Network.so.5, libQt5Svg.so.5, libQt5PrintSupport.so.5, libQt5Widgets.so.5, libQt5Gui.so.5, libQt5Core.so.5 That results in this list of dependencies with USE=qt5: dev-qt/qtcore:5= dev-qt/qtgui:5= dev-qt/qtnetwork:5= dev-qt/qtprintsupport:5= dev-qt/qtsvg:5= dev-qt/qtwidgets:5=
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9fcb5e6cab02c502052772dd715c80299b8f5bcc commit 9fcb5e6cab02c502052772dd715c80299b8f5bcc Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-11-19 14:00:04 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2017-11-19 14:35:49 +0000 sci-visualization/gnuplot: Switch from Qt4 to Qt5. Suggested-by: Andreas Eckstein <andreas.eckstein@gmx.net> Closes: https://bugs.gentoo.org/594570 Package-Manager: Portage-2.3.14, Repoman-2.3.6 sci-visualization/gnuplot/gnuplot-5.0.7.ebuild | 21 ++++++++++----------- sci-visualization/gnuplot/gnuplot-5.0.9999.ebuild | 21 ++++++++++----------- sci-visualization/gnuplot/gnuplot-5.3.9999.ebuild | 21 ++++++++++----------- 3 files changed, 30 insertions(+), 33 deletions(-)
