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

Hello Marcus,
>
Hey Carsten!

Back from vacation. :)

> > The fix is to add quotes to the middle part:
> > 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,.)

> > 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.)

> 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.

> > I'm not sure how well cmake supports Qt5.
> Since KDE uses cmake the Qt support is generally very good.
>
> Good to know.

> > (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.
> From a quick look at the cmake files, please try setting
> QT5_CMAKE_DIR to your <Qt5>/lib/cmake dir or alternatively
> QT5_BASE_DIR to the root of your Qt5 installation - otherwise OpenSG
> will only look for Qt4 if I'm reading it correctly.
>
> QT5_BASE_DIR seemed solve the detect-Qt5 problem. Nice. Thanks!

> CMake these days is trying to move away from the use of Find*.cmake
> modules (for software built with cmake anyway) and instead prefers that
> during the build/install step a package writes a file <foo>-config.cmake
> that contains the necessary info to locate headers and libs [1].
>
> Makes it easier to select the right version if you have several versions
of a package installed, I assume.

> CMake 2.8.12 should be fine, the support for Qt5 in the OpenSG build has
> been there before the cmake 3 release.
>
> Got it. Thanks! :)

/Marcus


2014-06-27 10:37 GMT+02:00 Marcus Lindblom Sonestedt <ma...@yar.nu>:

> 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
>
>
>
>
> 2014-06-27 9:08 GMT+02:00 Marcus Lindblom Sonestedt <ma...@yar.nu>:
>
> 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
>>
>>
>
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to