[Opensg-users] OpenSG2 - OpenEXR-cmake fix + failure to find Qt5

[Marcus Lindblom Sonestedt]

Hi,

(long time, no see, guys. I hope you're all doing well ;-)

We're upgrading our compiler (VS2008->2013) and third-party libraries, and
I'm running into cmake configure problems with OpenSG, which is not my
forte, yet.

(I'll be sure to post any fixes we implement to make stuff work with VS2013
and Qt5, of course)

Anyway, OpenEXR configuration fails with this error:

CMake Error at CMake/FindOpenEXR.cmake:70 (FILE):
file FILE([TO_CMAKE_PATH|TO_NATIVE_PATH] path result) must be called with
exactly three arguments.
Call Stack (most recent call first):
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:343 (OSG_FIND_PACKAGE)
CMakeLists.txt:591 (OSG_CONFIGURE_OPENEXR)

The line (70) is:
FILE(TO_CMAKE_PATH ${OPENEXR_INCLUDE_DIR} OPENEXR_INCLUDE_DIR)

And the result of OPENEXR_INCLUDE_DIR is this:

c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include;c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include/OpenEXR

The fix is to add quotes to the middle part:
FILE(TO_CMAKE_PATH "${OPENEXR_INCLUDE_DIR}" OPENEXR_INCLUDE_DIR)

At least it does not error out, but it still fails to find the libraries. I
don't care much as we don't use the EXR file-format currently. I suppose it
can be fixed by pointing to those support libs.


Btw, the supportlibs.7z file/directory is from 2009 (i.e. the time we built
OpenSG, supplied by you guys), but it should still work, right? (unless I
need to recompile them with VS2013 too... augh)

The related cmake options I set (which are set from a python build file,
hence the odd syntax):

'-DOSG_USE_OSGSUPPORT_LIBS=ON',
'-DOSG_USE_STATIC_SUPPORT_LIBS=ON',
'-DOSG_SUPPORT_ROOT=%s' % module.supportlibs,
'-DPNG_INCLUDE_DIR=%s' % pj(module.supportlibs, 'include'),

Anyway, I'm perfectly happy to compile without OpenEXR, which we don't use
at the moment.



It also fails to find Qt5, but that's only a warning. The only related
output is w.r.t Qt4:

CMake Warning at
c:/_work/_unzip/cmake/cmake-2.8.12.2-win32-x86.7z/cmake-2.8.12.2-win32-x86/share/cmake-2.8/Modules/FindQt4.cmake:659
(message):
C:/Code/tpd-build/Libs/Qt/qt-repo/qtbase/bin/qmake.exe reported
QT_INSTALL_LIBS as "c:/_work/C_Code/tpd-build/tmp/qt/lib" but QtCore could
not be found there. Qt is NOT installed correctly for the target build
environment.
Call Stack (most recent call first):
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:758 (OSG_FIND_PACKAGE)
CMakeLists.txt:700 (OSG_CONFIGURE_QT)

I'm not sure how well cmake supports Qt5.

(The qmake.exe it finds is Qt5.3.1. qmake.exe I built myself. Also, in the
<dir>/qt/lib there is a Qt5Core.lib, so it should be ok.)

Do I need to do anything special to enable Qt5 (as opposed to 4?).
Qt5 seems to be supported as it appears in the files, but theres nothing in
the output indicating that it even tries to look for Qt5.

The resulting configure output has a few lines like:
Dependency (Qt{4|5}) not found, can not build (OSGWindowQT4
/ OSGContribCSMQt)

But there's no FindQt5 in cmake/modules nor any references to 5 in
FindQt.cmake?


I'm using cmake version 2.8.12.2, by the way. (I just noticed 3.0.0 came
out, but that's probably too bleeding an edge to tamper with, or is it
required for Qt5 support?)

Cheers,
/Marcus

[Carsten Neumann]

Hello Marcus,

Post by Marcus Lindblom Sonestedt
(long time, no see, guys. I hope you're all doing well ;-)

good to see you again!

Post by Marcus Lindblom Sonestedt
We're upgrading our compiler (VS2008->2013) and third-party libraries,
and I'm running into cmake configure problems with OpenSG, which is not
my forte, yet.
(I'll be sure to post any fixes we implement to make stuff work with
VS2013 and Qt5, of course)
file FILE([TO_CMAKE_PATH|TO_NATIVE_PATH] path result) must be called with
exactly three arguments.
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:343 (OSG_FIND_PACKAGE)
CMakeLists.txt:591 (OSG_CONFIGURE_OPENEXR)
FILE(TO_CMAKE_PATH ${OPENEXR_INCLUDE_DIR} OPENEXR_INCLUDE_DIR)
c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include;c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include/OpenEXR
FILE(TO_CMAKE_PATH "${OPENEXR_INCLUDE_DIR}" OPENEXR_INCLUDE_DIR)
At least it does not error out, but it still fails to find the
libraries. I don't care much as we don't use the EXR file-format
currently. I suppose it can be fixed by pointing to those support libs.

Yea, quoting of paths can be a little tricky in cmake, due to the ...
uhm ... unique way cmake stores lists of strings and what effect that
has on paths that contain spaces ;)
It's possible that we get this slightly wrong elsewhere.

Post by Marcus Lindblom Sonestedt
Btw, the supportlibs.7z file/directory is from 2009 (i.e. the time we
built OpenSG, supplied by you guys), but it should still work, right?
(unless I need to recompile them with VS2013 too... augh)

yes, AFAIK MS does not promise ABI compatibility across compiler
versions and libraries compiled with different compiler versions is (in
my limited experience) often the source of _very_ interesting linker errors.
Gerrit put a lot of effort (semi-)automating the support libs build,
please see Support/ReadMe.txt for build instructions.

Post by Marcus Lindblom Sonestedt
It also fails to find Qt5, but that's only a warning. The only related
CMake Warning at
c:/_work/_unzip/cmake/cmake-2.8.12.2-win32-x86.7z/cmake-2.8.12.2-win32-x86/share/cmake-2.8/Modules/FindQt4.cmake:659
C:/Code/tpd-build/Libs/Qt/qt-repo/qtbase/bin/qmake.exe reported
QT_INSTALL_LIBS as "c:/_work/C_Code/tpd-build/tmp/qt/lib" but QtCore could
not be found there. Qt is NOT installed correctly for the target build
environment.
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:758 (OSG_FIND_PACKAGE)
CMakeLists.txt:700 (OSG_CONFIGURE_QT)
I'm not sure how well cmake supports Qt5.

Since KDE uses cmake the Qt support is generally very good.

Post by Marcus Lindblom Sonestedt
(The qmake.exe it finds is Qt5.3.1. qmake.exe I built myself. Also, in
the <dir>/qt/lib there is a Qt5Core.lib, so it should be ok.)
Do I need to do anything special to enable Qt5 (as opposed to 4?).
Qt5 seems to be supported as it appears in the files, but theres nothing
in the output indicating that it even tries to look for Qt5.

[Marcus Lindblom Sonestedt]

Hi,

The only compile error I got was the streaming of an std::ostringstream in
OSGClusterwindow, line 235:

SFATAL << "Error starting: " << command.str() << std::endl;

I had to add ".str()" at the end of command, otherwise everything we're
using (sans Qt) builds and links in debug mode, so far.

/Marcus

Post by Marcus Lindblom Sonestedt
Hi,
(long time, no see, guys. I hope you're all doing well ;-)
We're upgrading our compiler (VS2008->2013) and third-party libraries, and
I'm running into cmake configure problems with OpenSG, which is not my
forte, yet.
(I'll be sure to post any fixes we implement to make stuff work with
VS2013 and Qt5, of course)
file FILE([TO_CMAKE_PATH|TO_NATIVE_PATH] path result) must be called with
exactly three arguments.
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:343 (OSG_FIND_PACKAGE)
CMakeLists.txt:591 (OSG_CONFIGURE_OPENEXR)
FILE(TO_CMAKE_PATH ${OPENEXR_INCLUDE_DIR} OPENEXR_INCLUDE_DIR)
c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include;c:/_work/_unzip/opensg/supportlibs.7z/supportlibs/include/OpenEXR
FILE(TO_CMAKE_PATH "${OPENEXR_INCLUDE_DIR}" OPENEXR_INCLUDE_DIR)
At least it does not error out, but it still fails to find the libraries.
I don't care much as we don't use the EXR file-format currently. I suppose
it can be fixed by pointing to those support libs.
Btw, the supportlibs.7z file/directory is from 2009 (i.e. the time we
built OpenSG, supplied by you guys), but it should still work, right?
(unless I need to recompile them with VS2013 too... augh)
The related cmake options I set (which are set from a python build file,
'-DOSG_USE_OSGSUPPORT_LIBS=ON',
'-DOSG_USE_STATIC_SUPPORT_LIBS=ON',
'-DOSG_SUPPORT_ROOT=%s' % module.supportlibs,
'-DPNG_INCLUDE_DIR=%s' % pj(module.supportlibs, 'include'),
Anyway, I'm perfectly happy to compile without OpenEXR, which we don't use
at the moment.
It also fails to find Qt5, but that's only a warning. The only related
CMake Warning at
c:/_work/_unzip/cmake/cmake-2.8.12.2-win32-x86.7z/cmake-2.8.12.2-win32-x86/share/cmake-2.8/Modules/FindQt4.cmake:659
C:/Code/tpd-build/Libs/Qt/qt-repo/qtbase/bin/qmake.exe reported
QT_INSTALL_LIBS as "c:/_work/C_Code/tpd-build/tmp/qt/lib" but QtCore could
not be found there. Qt is NOT installed correctly for the target build
environment.
CMake/OSGBuildFunctions.cmake:2672 (FIND_PACKAGE)
CMake/OSGConfigurePackages.cmake:758 (OSG_FIND_PACKAGE)
CMakeLists.txt:700 (OSG_CONFIGURE_QT)
I'm not sure how well cmake supports Qt5.
(The qmake.exe it finds is Qt5.3.1. qmake.exe I built myself. Also, in the
<dir>/qt/lib there is a Qt5Core.lib, so it should be ok.)
Do I need to do anything special to enable Qt5 (as opposed to 4?).
Qt5 seems to be supported as it appears in the files, but theres nothing
in the output indicating that it even tries to look for Qt5.
Dependency (Qt{4|5}) not found, can not build (OSGWindowQT4
/ OSGContribCSMQt)
But there's no FindQt5 in cmake/modules nor any references to 5 in
FindQt.cmake?
I'm using cmake version 2.8.12.2, by the way. (I just noticed 3.0.0 came
out, but that's probably too bleeding an edge to tamper with, or is it
required for Qt5 support?)
Cheers,
/Marcus

[Marcus Lindblom Sonestedt]

(Sorry that this ends up wrong in the threading...)

Hello Marcus,
Hey Carsten!

Back from vacation. :)

Post by Carsten Neumann

Post by Marcus Lindblom Sonestedt
FILE(TO_CMAKE_PATH "${OPENEXR_INCLUDE_DIR}" OPENEXR_INCLUDE_DIR)

Yea, quoting of paths can be a little tricky in cmake, due to the ...
uhm ... unique way cmake stores lists of strings and what effect that
has on paths that contain spaces ;)
It's possible that we get this slightly wrong elsewhere.
Ok. Good to know. I'll be on the lookout.

(Not that I have spaces in my paths when building stuff, but,.)

Post by Carsten Neumann

Post by Marcus Lindblom Sonestedt
Btw, the supportlibs.7z file/directory is from 2009 (i.e. the time we
built OpenSG, supplied by you guys), but it should still work, right?
(unless I need to recompile them with VS2013 too... augh)

yes, AFAIK MS does not promise ABI compatibility across compiler
versions and libraries compiled with different compiler versions is (in
my limited experience) often the source of _*very*_ interesting linker
errors.
Yes, especially with C++. I think they're planning to fix the runtime-lib

incompabilities in VS 2014 an onwards, so there only be one...

With pure C and where memory allocations/releases are kept to the same DLL,
you can get away with much more.
(Compare the Win32/OS libraries you link to in order to get anythning done
at the base line. No issues there.)

Post by Carsten Neumann
Gerrit put a lot of effort (semi-)automating the support libs build,
please see Support/ReadMe.txt for build instructions.
I've read that and gotten quite far.

OpenSG depends on quite a few libs so there's a bit of work to do on
Windows. Sigh.

If I need to compile zlib/pnglib etc, I'll probably host my compiled
supportlibs version somewhere to the benefit of others.

Post by Carsten Neumann

Post by Marcus Lindblom Sonestedt
I'm not sure how well cmake supports Qt5.

Since KDE uses cmake the Qt support is generally very good.
Good to know.

Post by Marcus Lindblom Sonestedt
(The qmake.exe it finds is Qt5.3.1. qmake.exe I built myself. Also, in
the <dir>/qt/lib there is a Qt5Core.lib, so it should be ok.)
Do I need to do anything special to enable Qt5 (as opposed to 4?).
Qt5 seems to be supported as it appears in the files, but theres nothing
in the output indicating that it even tries to look for Qt5.