2017-11-19 15:21 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001219Orfeo Toolbox (OTB)Generalpublic2017-07-13 15:34
Reporterrashadkm 
Assigned Torashadkm 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
Summary0001219: cannot rely on FindQt4.cmake distributed by CMake.
Description
We need a small minimal findQt4.cmake and avoid the one from cmake. It is buggy and creates a lot lot of problems for us.

For a start,
It first find qmake and then use qmake -query to get location of headers, mkspecs etc..

Why did ever they do this?

chance of having directories under install prefix of QT is almost zero. Maybe they do this for embedded platforms or mobiles or just to make life miserable for rest of world.

Now what is the problem with qmake -query? It hard coded the absolute installation path for everything expect qmake. moc, rcc, uic, mkspec, imports, etc..

why should I install qmake and then put the other tools moc, rcc; uic into a other folder? network share ?

I could go on with the issue with cmake's FindQt4.cmake. It is not bad that cmake did this way. But all my point is we don't need this one. simply a small FindQt4.cmake with some macros from existing code.

TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0003500

gpasero (administrator)

It is a limitation of Qt4 , let see what we can do.

~0003550

rashadkm (developer)

the issue with cmake's findQt4 is problem again. see this failing test http://dash.orfeo-toolbox.org/testDetails.php?test=40099215&build=235666
there are other starting with owTvQt.

and have a look at build notes.
http://dash.orfeo-toolbox.org/viewNotes.php?buildid=235666
I found this here:
//The Qt QTCLUCENE library
QT_QTCLUCENE_LIBRARY:STRING=/opt/local/lib/libQtCLucene.dylib

//Path to a library.
QT_QTCLUCENE_LIBRARY_DEBUG:FILEPATH=QT_QTCLUCENE_LIBRARY_DEBUG-NOTFOUND

//Path to a library.
QT_QTCLUCENE_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libQtCLucene.dylib

do we have a dependency to Qt CLucene. I don't think so. So when calling find_package(Qt4 REQUIRED). it fills QT_LIBRARIES with all found libraries. On linux we install only qtcore and qtgui. So not much problem there. Also remember only on macosx, qt "framework" drags all the system libraries.

Easy/temporary fix would be to use COMPONENTS in find_package call. But the original bug report about qmake -query still persists.

Any comments ?

~0003616

gpasero (administrator)

This FindQt4 also defines macros that we use, such as QT4_WRAP_CPP and others. I don't think we can avoid calling it.
I agree on the component list, we should give the list of the components we need. Speaking of OTB + MVD, we need QtCore, QtGui, QtXml, QtSql, and QtOpenGL.

The issue about "qmake -query" is a limitation of a Qt4 install : it wasn't meant to be relocatable. I don't think it is an OTB bug. Is it still possible for the user to enter the right QT libraries paths in the CMake cache ? If yes, we should document this trick.

~0003623

rashadkm (developer)

do we need QtXml and QtSql in monteverdi? I think the sqldb part is removed or has no effect in code.

regarding qt4_wrap_cpp, we don't need the complete functionality provided by cmake. having putting this macro into FindQt4.cmake would not be that hard.

zero-cost solution is your proposed workaround, set variables in cmake manually. But statistically (atleast in otb) zero/low cost solution are just the high price we pay later in time ;)

~0003711

rashadkm (developer)

Qt4Macros.cmake and UseQT4.cmake can be included in custom FindQt4.cmake. Unfortunately, they are not dependent on CMake's FindQt4.cmake

only thing blocking is usage of qmake -query to find include, headers, moc etc..

~0003768

rashadkm (developer)

cmake 3.5.1 has QT_BINARY_DIR which can used to set to <xdk install directory>/bin

and will solve the issue. But right we need to hardcode <xdk install directory>/bin. and use cmake -DQT_BINARY_DIR=<xdk install directory>/bin to find qt properly.

better is fix is to write FindQt4.cmake and include Qt4Macros.cmake. we will loose no other macros from cmake

~0004243

rashadkm (developer)

a workaround is documented in xdk readme.
closing this issue for now.
+Notes

-Issue History
Date Modified Username Field Change
2016-05-13 11:45 rashadkm New Issue
2016-06-10 10:32 gpasero Note Added: 0003500
2016-06-10 10:32 gpasero Assigned To => gpasero
2016-06-10 10:32 gpasero Status new => acknowledged
2016-07-04 09:52 rashadkm Note Added: 0003550
2016-07-29 14:53 gpasero Note Added: 0003616
2016-08-03 12:12 rashadkm Note Added: 0003623
2016-09-12 18:01 rashadkm Note Added: 0003711
2016-10-10 12:30 rashadkm Assigned To gpasero => rashadkm
2016-10-10 12:30 rashadkm Status acknowledged => assigned
2016-10-13 17:52 rashadkm Note Added: 0003768
2017-07-13 15:34 rashadkm Note Added: 0004243
2017-07-13 15:34 rashadkm Status assigned => closed
2017-07-13 15:34 rashadkm Resolution open => fixed
+Issue History