Summary: | licq won't compile against qt3 (it checks that by default) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andreas Waschbuesch <awaschb> |
Component: | New packages | Assignee: | Arcady Genkin (RETIRED) <agenkin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | g2boojum |
Priority: | High | ||
Version: | 1.0 RC6 r14 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andreas Waschbuesch
2002-03-11 05:37:15 UTC
Hi agenkin, You are the one who made the qt2/3 changes to the icq ebuild, and this appears to be realted to these changes, so I'm sending this to you. BTW, IMHO selecting qt2 or 3 based on what's installed is wrong. You should decide that you use qt3 (or 2 if there's a good reason for that) and depend on it, and that'll be that. Ebuilds aren't supposed to be influenced by what is installed, that's what dependencies are for. *** Bug 1479 has been marked as a duplicate of this bug. *** For the record, this was the reply to comment #1. --------------8<-------------8<--------------------- > Hi agenkin, You are the one who made the qt2/3 changes to the icq > ebuild, and this appears to be realted to these changes, so I'm > sending this to you. Hi, Dan: The problem with this bug seems to arise from licq trying to be compiled against qt3, *and* kde2, as far as I can guess. First off, a bit of pre-history: - I did not introduce qt3 compatibility into licq's ebuild. The ebuild had ">=qt-2.X.X" as a depdency. If you tried to merge licq without qt libraries installed, the portage system would build QT3 for you, and then fail to compile licq because the pass to /usr/qt/2 was hard-coded into it. - What I did was put in a hack (which is admitted in the ebuild) that would simply allow the build process to complete. Now, we need to find a solution for this problem. As I don't use, nor know anything about KDE, and you seem to be the KDE guy, I'd like to hear your thoughts on the matter. In my opinion, since licq compiles and works properly with Qt3 (at least without KDE support), it would be wrong to not support it, and force the user to install qt2 just for the purpose of licq. What would you say about the attached patch? Basically, it builds against qt2 if kde is in USE variable; otherwise, it builds against whatever version of qt is available. > BTW, IMHO selecting qt2 or 3 based on what's installed is wrong. You > should decide that you use qt3 (or 2 if there's a good reason for > that) and depend on it, and that'll be that. Ebuilds aren't supposed > to be influenced by what is installed, that's what dependencies are > for. So, how would I detect in the ebuild what version of QT the user has chosen, other than test what's installed? Or do you mean that I, as an ebuild author should make the choice? In that case, there is no need to make that choice, since licq compiles against any version of QT, as it seems, except when compiled with KDE support, and the installed version of KDE is 2 (I'm guessing that it might compile against qt3 and kde3, but that's just a guess). Below is the patch I proposed. Something that looks identical has been committed into the CVS, so I propose closing the bug. --- licq-1.0.4-r1.ebuild Tue Feb 19 15:54:58 2002 +++ licq-1.0.4-r2.ebuild Tue Mar 12 20:55:19 2002 @@ -12,6 +12,7 @@ SLOT="0" DEPEND="$DEPEND ssl? ( >=dev-libs/openssl-0.9.6 ) + kde? ( <x11-libs/qt-3.0.0 ) qt? ( >=x11-libs/qt-2.2.0 )" use kde && need-kde 2.1 @@ -35,12 +36,14 @@ if [ "`use qt`" ] then - # A hack to build against the latest QT: + # A hack to build against QT 3 local v for v in /usr/qt/[0-9] do [ -d "${v}" ] && export QTDIR="${v}" done + # If using KDE, use QT2 + use kde && export QTDIR=/usr/qt/2 cd plugins/qt-gui-1.0.4 make -f Makefile.cvs || die use kde && kde_src_compile myconf |