But I also found rev. 11354 (from Wang Rui) added a change in OsgMacroUtils which adresses a similar issue: Wang told the "../../bin" prefix wasn't working. However I think the fix isn't correct because it checks the MSVC version instead of the CMake version. Here is my fix, against latest trunk (root CMakeLists.txt, and CMakeModules/OsgMacroUtils.cmake).
Tests I made:
| Unix Makefiles | MSVC 9 | MSVC 10 x64
---------------------------------------------------
CMake 2.4 | | OK | N/A
CMake 2.6.4 | | OK | N/A
CMake 2.8.0 | | OK | broken support?
CMake 2.8.2 | | OK | OK
"
changed extensions from .c to .cpp and got compiling as C files as part of the osg core library.
Updated and cleaned up the rest of the OSG to use the new internal GLU.
1. Install the .pc file for osgIntrospection only if it is compiled,
instead of unconditionally.
2. New .pc file for osgQt, also created only if that library is actually
compiled.
"
Mathieu Marache, he added the last missing piece to this puzzle.
I think it is safe to commit these changes to trunk, as the traditional
way via dylibs should work as before.
Here's some more info how to get frameworks:
With these modifications it is possible to compile frameworks on OS X,
when you set the Cmake-option OSG_COMPILE_FRAMEWORKS to true. If you
want to embed the frameworks in your app-bundle make sure to set
OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR accordingly.
You'll have to build the install-target of the generated xcode-projects
as this sets the install_name_dirs of the frameworks and plugins."
currently only Debug appends "d" so the Release and MinSizeWithDebInfo
(and MinSizeRel) all produce the same filenames. This set of changes
lets each build type have a cmake defined string appended, defaulting
to Release none, Debug d, RelWithDebInfo rd, MinSizeRel s. But a user
still can have Release, RelWithDebInfo, and MinSizeRel to produce the
same filenames. It does so by setting the preprocessor define
OSG_LIBRARY_POSTFIX in src/osgDB/CMakeLists.txt to one of the
previously defined cmake variables CMAKE_DEBUG_POSTFIX
CMAKE_RELEASE_POSTFIX CMAKE_RELWITHDEBINFO_POSTFIX
CMAKE_MINSIZEREL_POSTFIX. This method cuts down on the #ifdef _DEBUG
#else preprocessor directives in Registry.cpp as the extension is
always passed in OSG_LIBRARY_POSTFIX. That and __MINGW32__ didn't
have the _DEBUG check which looks like a bug."
Introduced the OSG_NOTIFY_DISABLE Cmake variable + include/osg/Config #define to control whether the OpenSceneGraph build
should disable the notification system completely. By setting OSG_NOTIFY_DISABLE to ON in CMake and then rebuilding the
the OSG you can get a slightly smaller (~1%) and more slightly efficient library which can be good for shipping applications,
but with downside of reduced ability to detect runtime problems and their causes.
almost all Linux distributions. Although it is 100% compatible with ld,
by default it gives an error if a library has unresolved symbols at link
time, that is, it has set -Wl,--no-undefined by default. Debian folks
have found that libosg.so and libosgDB.so use some functions belonging
to libdl.so {dlsym,dlopen,dlclose,dlerror} without linking to it.
My changes link those two libraries to libdl.so explicitly in the same
way it is already done for libm.so and librt.so."
synchronization, improve capture device support.
here how to use it to display a capture device:
osg::Options* options = new osg::Options;
options->setPluginStringData("captureWantedWidth", "800");
options->setPluginStringData("captureWantedHeight", "600");
options->setPluginStringData("captureWantedFps", "30");
options->setPluginStringData("captureVideoDevice", "USB Video Device" );
options->setPluginStringData("captureSoundDevice", "");
then
osgDB::readImageFile("capture.directshow", options)
you can use a graphedit application to list devices available in
directshow.
for classic avi file you just need to do a
osgDB::readImageFile("file.avi.directshow");
You will need of course to install the codec needed by directshow to
read the avi files.
I recommand this tool http://avicodec.duby.info/, that check which
video/sound codec is needed to play an avi file.
You can test it with the osgmovie example.
"
settimeofday), OSG animations will freeze your application because
osg::Timer uses gettimeofday internally on non-Win32 platforms. This
is wrong and should be replace with times(2) or clock_gettime(2).
The attached patch fixes the issue in a binary-compatible way by using
clock_gettime when it's available, and falling back to gettimeofday
when it's not."
Most notable the __hpux define stuff. The __hpux__ variant seems to be not
defined which resulted in a compile error at this time. Consequently I have
replaced all occurances of __hpux__ with __hpux. And huge surprise: now osg
plugins are found and loaded correctly ...
The next notable one is the MSVC_IDE fix which makes the nmake Makefiles cmake
generator target behave like the ide one. Showed up because I started to do
scripted builds with nmake instead of devenv...
The rest is the usual bunch of stuff that just happens during normal
coding ..."
Introduced a new callback osgDB::FindFileCallback that overrides the default behavior of findDataFile/findLibraryFile.
Introduced support for assigning ReaderWriter::Options directory to PagedLOD.
Introduced new osgDB::FileLocationCallback for assistancing the DatabasePager to know when a file is hosted on a local or remote file system.
Converted Present3D across from using libxml2 to using the new osgDB::XmlNode/XmlNode::Input classes from Xml Parsing.
This changes removes the dependency on libxml2, and allows the present3D application and p3d to work on all platforms.
http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/42400
Since this is a workaround for a bug in a beta OS (which may or may not be fixed, since it's mentioned in their release notes so they may just leave it as it is) I've marked the option as advanced, default to OFF, and clearly documented it as being useful for Windows 7 only. I'd like to be able to test for Windows 7 directly instead of the blanket IF(WIN32), but I can't figure out if this is possible in CMake.
Here's the modified CMakeLists.txt. It's a small change, with low impact, but will be useful to others who test out this OS and when it comes out. Note that I'm not familiar with this option in general, and didn't get any feedback to my questions in the above-mentioned thread, one of which was: Could we just add this option to all builds? What is the impact? That's still unclear to me, but without it OSG executables don't build, and the article I linked didn't seem to present any ill effects to enabling the option."
1. Makes IF/ELSE/ENDIF code blocks easier to read by replacing code like this:
IF(FOO)
MESSAGE("FOO is true")
ELSE(FOO)
MESSAGE(" ??? ELSE(FOO)??? ")
ENDIF(FOO)
with this:
IF(FOO)
MESSAGE("FOO is true")
ELSE()
MESSAGE("FOO is clearly false")
ENDIF()
2. Also adds an ELSEIF() where it makes sense to do so (safe to use as of CMake 2.4.4)"
talking about in the LIB_POSTFIX thread. It is a bit verbose perhaps
and the message I emit during the make install step flashes by and
gets burried under all "installing..." and/or "up-to-date..."
messages. I have posted on the cmake mail list on ways to do this
better.
The submission adds:
* message to user during configuration that s/he's eventually going o
install to ${CMAKE_INSTALL_PREFIX}lib${LIB_POSTFIX}
* if system has /etc/ld.so.conf.d and it is a dir generates
packaging/ld.so.conf.d/openscenegraph.conf and creates a custom target
for installing it (target must be run explicitly of course). User is
notified of this during configuration (may not be necessary)
* emit a message during installation that libraries are put in
<same-as-above>. This message unfortunately gets emitted to soon for
the user to see it
* I added "COMPONENT libopenscenegraph-dev" to the pkgconfig.pc's
install command
* Moved the section with OSG_CONFIG_HAS_BEEN_RUN_BEFORE as close to
the end of CMakeLists.txt as I dared. This is the intent of this
construct I think."
openscenegraph.pc and openthreads.pc files with OSG's installation values.
Then I install those files into the expected path for pkg-config (this can
also be modified through PKG_CONFIG_PATH environment variable). Therefore
those of us who are using pkg-config for linking can easily select which
version of OSG we want to use."
name of the top folder in each package to OpenSceneGraph-x.y.z
Noone else has had an opinion on whether compiler and it's version
should be part of the package filename on their platform/setup so I'll
leave it as is. That is - No action is taken for compilers other than
msvc but one can easily add this information to the cmake cache
regardless of platform.
"
streamlined for tgz and has most of the features that Robert, J-S and
Sukender requested in december. I have an idea of how to discover the
vc80 sp1 or not but haven't had time to implement. The script is
completely reworked and now doesn't include cmakes' bundled
CPack.cmake script at all. In summary:
* filenames are
<package>-<osgversion>-<platform>-<arch>[-compiler]-<configuration>.tar.gz,
ex. libopenscenegraph-2.7.9-Linux-i386-Release.tar.gz,
libopenthreads-dev-2.7.9-win32-x86-vc80sp1-Debug.tar.gz
* targets (projects in msvs) are generated for each specified
component, a target that packages everything that is installed
(openscenegraph-all) and there's a target for running all other
packaging targets (Package ALL on msvs, package_ALL in unix
makefiles).
* It is possible to set the compiler in ccmake (cmake-gui, whatever you use)
* the top folder in packages is the same for all packages (OpenSceneGraph-x.y)
* the packaging support is limited with cmake-2.6.0 and not as
dynamic. With cmake-2.6.1 and later building the gdal plugin (for
example) will create a package_libopenscenegraph-gdal target. With
cmake-2.6.0 only the ones that are always built (libopenscenegraph,
libopenscenegraph-dev, openscenegraph, libopenthreads,
libopenthreads-dev
* i found a better way to decide whether cpack is available to guard
the BUiLD_OSG_PACKAGES option"
of cmake-2.6.0. As a side note I just installed cmake from the ubuntu
repositories and got cmake-2.6.0-4ubuntu2 and this one produced the
currect CMAKE_CXX_FLAGS_RELEASE (-O3 -DNDEBUG). This CMakeLists is
tested on linux with cmake versions 2.4.8, 2.6.0, 2.6.2 and
2.6.0-4ubuntu2
* Added quotes around CMAKE_CXX_FLAGS var to help cmake-2.6.0 pick up
that it really is a string value
* Removed quotes around values that we set in
OSG_AGGRESIVE_WARNING_FLAGS. This makes OSG_AGGRESIVE_WARING_FLAGS be
of LIST type so the foreach constructs can behave as I planned."
that set aggressive warnings in CMAKE_CXX_FLAGS and the on that
processes the source tree(s) or the newly set flags wouldn't take
effect until second consecutive configure.
I also replaced the internally cached variables that managed the
aggresive warnings with explicit adding and removing of flags in
CXX_FLAGS
For apple we first required min cmake version 2.6.0 and then had code
warning about using 2.4.x"
* Removed processing of include/OpenThreads in the OpenSceneGraph refman
* Clears the mark_as_advanced property of the BUILD_DOCUMENTATION
cmake variable (so it gets visible in simple view).
"
Updated all doxyfiles under doc/Doxyfiles. They are now all processed
by cmake but make targets are only generated for
OpenSceneGraphReferenceDocs and OpenThreadsReferenceDocs. The others
can be run with doxygen directly in <builddir>/doc.
Fixed a copy-paste in openthreads sproc and pthreads CMakeLists
Added the osg logo to the html footers
Added possibility to get generation of chm files.
CMakeLists (toplevel):
Added install of osg and ot reference docs. This also generates
packaging targets of openscenegraph-doc and openthreads-doc if you
have packaging enabled
Removed the unused USING_OP_OT_TRIPLE_SET since there was no way of
enabling it anyway
Removed BUILD_REF_DOCS. IMO it was redundant - BUILD_DOCUMENTATION
does the same thing and we get that anyway from including
Documentation.cmake.
OsgCPack.cmake:
Removed generation of PACKAGE_SRC for msvc
Added special handling for -doc packaging targets - they don't require
system, architecture or compiler"
Better package naming. example
openscenegraph-core-2.7.7-Linux-i386.tar.gz on my ubuntu laptop and
openscenegraph-core.2.7.7-win32-x86-vc80.tar.gz on winxp.
CMakers will not get options for selecting compression format. TGZ
goes for all platforms (on win32 I use 7zip)
The wrappers is now given the COMPONENT name
libopenscenegraph-wrappers. Feel free to change the name.
On windows with visual studio the OsgCPack script make some efforts to
discover the compiler used but support is a bit poor so I've given
CMake acces to OSG_CPACK_COMPILER to provide some mean to name the
compiler.
stop
The platform part is taken from CMAKE_SYSTEM_NAME and for windows I
change this to win32 or win64 based on CMAKE_CL_64. This might not be
necessary if the arch part has that information. This information is
taken from CMAKE_SYSTEM_PROCESSOR. I only have 32bit here so if some
of you could uncomment line 15,16 in OsgCPack.cmake and report what
cmake report it would be nice. I'm especially interested anything but
win32 and linux32"
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
I have not reverted added Compiler options. I assume that one may want to have warnings enabled for the application but may not want to see them while OSG libraries and examples compile.
Modified files:
osg/Export - now explicitly includes osg/Config to make sure OSG_DISABLE_MSVC_WARNINGS is read
osg/Config.in - declares OSG_DISABLE_MSVC_WARNINGS flag to be added to autogenerated osg/Config
CMakeLists.txt - declares OSG_DISABLE_MSVC_WARNINGS as option with default ON setting
"
I suggest moving the definition of OSG_DEFAULT_LIBRARY_PATH (which is responsible for this global rebuild) into osgDB/CMakeLists.txt which is the only library in the code where this definition is (and is likely ever to be) used. This way if the user changes it, only osgDB will rebuild."
set to off. But could be activated/decativated via CMake as well as system
environment variable. I also modified src\osgViewer\CMakeLists.txt to turn
off this workaround by default as suggested."
CMakeLists.txt changes: "I installed latest Cmake(2.6.1) on a new machine and got a CMP008
warning from cmake. This fix set up osg to use the old behaviour which
have worked before. We might set this to NEW but I need to do more
testing first. I'l be able to test this on winxp with msvc80/90 and
ubuntu hardy with gcc-4.2.
quote from cmake cvs log
policy CMP0008 to decides how to treat full path libraries that do not
appear to be valid library file names. Such libraries worked by
accident in the VS IDE and Xcode generators with CMake 2.4 and below."
OsgMarcroUtils.cmake changes: "On Philips suggestion truncated a redundant if/else construction in
OsgMacroUtils to avoid developer warnings in cmake-2.6.1 concerning
cmake policy CMP0008 which allows full paths to libraries only with
valid library names
"
mode. Nevertheless, the code doesn't acknowledge that, so I had problems with
debug versions of the library not being able to open their plugins whereas
the release versions worked fine.
I have made the same changes in Registry.cpp that are available for the rest
of platforms appending that "d" to their plugins. I have also updated the
CMakeLists.txt file to get "_DEBUG" defined at compilation time. I have
copied the already existent conditional block because of cmake's bizarre
operator precedence. Since Cygwin defines both CYGWIN and WIN32, the
following would suffice:
IF(CYGWIN OR UNIX AND NOT WIN32 AND NOT APPLE)
Sadly, it actually doesn't work, so I wrote a new conditional block just for
Cygwin. I could join the two blocks when the parentheses support is added in
newer versions of cmake."
I needed a -DCMAKE_DEBUG_POSTFIX="d" not a -D"CMAKE_DEBUG_POSTFIX=d".
This corrects the build for the CMake 2.4 and 2.6 series
The error was in compiling osgDB/Registry.cpp
"
- Added osgviewerCocoa example to APPLE builds
- Fixed corrupt Xcode project generation with CMake 2.6 dealing with ADD_DEFINITIONS and CMake Policy CMP0005 on Leopard
- Resolved CMP0006 warning for examples and programs by setting BUNDLE DESTINATION to same as RUNTIME DESTINATION with CMake 2.6
- Fixed freetype plugin on Leopard to avoid OpenGL linking problem
- Figured out how to use a custom Info.plist included in the project (see osgviewerCocoa application CMakeLists.txt)"
first post:
"I had the problem that debug and release version of the plugins had the same name under linux. These minors modification to Registry and the CMake support files enable to have both Release and Debug version of the plugins to coexist and be found by there respective runtimes."
follow up post:
"I've gone ahead and added a preprocessor directive with the editable CMAKE_DEBUG_POSTFIX. I modified Registry.cpp to take this new preprocessor directive called OSG_DEBUG_POSTFIX while looking for libraries in Debug mode for the windows (msvc) and the linux platforms.
MinGW, cygwin and Apple are still left out this proposal."
Notes from Robert Osfield, completed the work in change d entries to use OSG_DEBUG_POSTFIX
The reason is if you want to build an application that use a library that use openscenegraph you have to build the full chain in debug or in release.
On windows you have no choice, but on linux you can link with both version without rebuilding everything ...
The patch consist only to change the line on one line
SET(CMAKE_DEBUG_POSTFIX "d")
with
SET(CMAKE_DEBUG_POSTFIX "d" CACHE STRING "add a postfix, usually d on windows")"
