Hello DeadParrot,
It's strange you experience problems with the osg build system...
I've built it a lot of time both in 32 and 64 bit without big issues like you
describe
The recurent problem I have is with the png support that need a two time cmake
configuration step:
1) set the 3rdParty folder then configure (png lib is not detected as it come
after zlib)
2) re-configure (this time zlib is set to found and png detection works)
But this so-called "problem" is not longer one until you know that
My guess is that you don't setup correctly VisualStudio environment with the
vcvars.bat
Cheers
DeadParrot wrote:
>
> > Hello,
> >
> > I recently built OSG 3.4.0 on Windows with Visual C++ 2015 and Intel C++
> > 2016
> > using Qt 5.6. I am sharing the CMake configuration adjustments I neede to
> > make.
> > Provisos are that I'm not a CMake expert and my focus was just on Windows
> > with
> > these compilers and my 3rd party library builds, so I may not have made the
> > most elegant and general purpose modifications. But I hope that the OSG
> > CMake
> > experts can benefit from some of this.
> >
> > Here is an overview of the attached files and the modifications. The
> > attached
> > files have the modifications to the current git master branch.
> >
> >
> > CMakeLists.txt
> >
> > CMAKE_STATIC_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS and
> > CMAKE_EXE_LINKER_FLAGS:
> > I needed to add the path to Windows dev libraries to get linking to succeed.
> > For portability this should probably be done on the cmake command line but
> > I did
> > it in CMakeLists.txt in the MSVC section this way (for my current SDK):
> > set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS}
> > /LIBPATH:"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64""
> > CACHE INTERNAL "" FORCE)
> > set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> > /LIBPATH:"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64""
> > CACHE INTERNAL "" FORCE)
> > set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /LIBPATH:"C:/Program
> > Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64"" CACHE INTERNAL ""
> > FORCE)
> > I'm not sure if this can be done portably within CMakeLists.txt.
> >
> >
> > CMakeModulesFindFreetype.cmake
> >
> > The freetype include path structure has changed
> >
> > I needed to add freetyped to the NAMES for the debug build to find the
> > library
> >
> >
> > srcOpenThreadsqtCMakeLists.txt
> >
> > For Qt5 the use of qt5_use_modules and I replaced it with
> > FIND_PACKAGE( Qt5 REQUIRED Core )
> > target_link_libraries( ${LIB_NAME} Qt5::Core )
> > I'm not completely sure the FIND_PACKAGE is needed here but it seems that it
> > should be since we've only found Qt5Widgets so far.
> >
> >
> > srcosgPluginsfreetypeCMakeLists.txt
> >
> > I needed to add the PNG lib to:
> > SET(TARGET_LIBRARIES_VARS FREETYPE_LIBRARY PNG_LIBRARY )
> > since I built freetype with PNG support. But I also built freetype with
> > zlib support yet I didn't need to add ZLIB_LIBRARY here. I'm not sure how
> > to craft this to smoothly handle freetype libs built with different feature
> > sets.
> >
> >
> > srcosgQtCMakeLists.txt
> >
> > For Qt5 I had to change to doing
> > FIND_PACKAGE( Qt5 REQUIRED Core Gui OpenGL Widgets )
> > before SETUP_LIBRARY and I changed the qt5_use_modules call after
> > SETUP_LIBRARY to
> > target_link_libraries( ${LIB_NAME} Qt5::Core Qt5::Gui Qt5::Widgets
> > Qt5::OpenGL )
> >
> > I also split out the Qt4 debug support based on information that some CMake
> > versions
> > weren't adding the "d" suffix to library names like QT_QTCORE_LIBRARY on
> > Windows in
> > debug builds. This may be unnecessary now or might never have been
> > necessary.
> >
> >
> > Cheers,
> > Stuart
>
>
> ------------------
> Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67106#67106
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
