[Clfs-dev] CBLFS -- query about cmake & qt4

[db m]

----------------------------------------
> Date: Tue, 7 Apr 2009 20:15:43 -0400
> From: jciccone
> To: clfs-dev
> Subject: Re: [Clfs-dev] CBLFS -- query about cmake & qt4
>
> db m wrote:
>> Greets,
>>
>> I just stumbled across a package (lmms) that uses the cmake
>> build system for compilation - the package requires qt4, but
>> cmake fails to find the qt4 qmake binary...
>>
>> This is likely to happen only if you have qt4 installed in /opt
>> and you have qt3 installed in /usr -- the cmake control files
>> (/usr/share/cmake-{version)/Modules) expect to find qt4 in
>> /usr, and failing that, will walk the current $PATH looking for
>> a valid qt4 qmake binary named 'qmake-qt4' or 'qmake4' - we
>> do not create this during the CBLFS qt4 build procedure.
>>
>> We do set the QT4DIR variable (ignored by cmake) and include
>> /opt/qt4/bin in $PATH, but cmake must find qmake-qt4 (or qmake4)
>> in $PATH (these can be symlinks to /opt/qt4/bin/qmake) or else the
>> cmake system will error out.
>>
>> Although I could update the wiki page to add such a symlink
>> and effectively fix this boofle, it occurs to me that in the case
>> of a multilib build....where /opt/qt4/bin/qmake is a symlink back
>> to /usr/bin/multiarch_wrapper.....such an approach is not correct.
>>
>> i've put off touching the wiki on this, and instead air the situation
>> here hopeful of some advice with this....anyone have any ideas?
>>

Joe said;

> I have yet to find a good solution for qt3 and qt4 existing on the same
> system. I opted to just not install qt3 anymore and only put qt4 in. I
> simply refuse to use cmake, it sucks.
>
> I'm wondering if a custom wrapper should be written for qmake, moc, and
> uic. It would be easy enough to do.
>

...after a bit of checking, I've found that temporarily moving /usr/bin/qmake
(part of qt3 installation) out of the PATH, gets cmake around this problem.
It would seem that although the findqt4.cmake control file can find the qt4
qmake in /opt/qt4/bin, the test case fails....(I'm suspecting it erroneously 
tests /usr/bin/qmake instead, perhaps because it's at the 'front' of $PATH)...

....the names qmake4 & qmake-qt4 I believe are part of the windows/mac 
qt4 ports -- symlinking the qt4 qmake to one of these so named files does
get around this issue too, but I'd probably call this solution an ugly hack....
the real fix is to get the findqt4.cmake control file working properly....

...as stated, you won't strike this problem if qt4 is installed in /usr  -- that said,
if you then install qt3 in /opt and need to use cmake to compile against qt3,
you will end up with pretty much the same issue...

..if you had both qt trees installed in /opt, you could also get around this by
manipulating the order of $PATH so that the first qmake cmake finds, is
the qt4 qmake (or qt3 qmake as appropriate)... 

I too wish I could avoid cmake, however a couple of apps I regularly use
employ cmake, so I'm stuck with that sucking sound. I'm unsure whether
custom wrappers for qmake and friends will improve things - I doubt very
much they'd help here with cmake, and the rest of the time using the 
configure method I've had  no trouble pointing things at the qt installation
that's required....

regards,

Don  


_________________________________________________________________
Looking to change your car this year? Find car news, reviews and more 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT