Attached is a modified FindOpenEXR.cmake module that locates IlmIlf and Half, as well as a modified exr/CMakeLists.txt that picks up this change.
Also attached are some typo fixes for CMakeModules.
Cheers,"
Also, I've modified the FindCOLLADA.cmake to locate the current 2.1 versions of the COLLADA DOM in the build directories under VC8. I've also added a COLLADA_LIBRARY_DEBUG spec. Other flavors may be added depending on compiler version and DOM version."
"
and a later post the same osg-submissions thread:
"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."
And another post from Blasius on this topic:
"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.
In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))
should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))
The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.
Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.
OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
MSVC_VERSIONED_DLL, NMake makefiles and CMake 2.6.2.
The compilation fails because it tries to copy ot11-OpenThreads.lib to
OpenThreads.lib which is valid for the 2.4.x era of CMake but not
anymore in 2.6.x era.
The provided file from the CMakeModules directory adds a tests on the
CMake version and corrects this. Works for me now."
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
"
MemoryBarrier() is used in the implementation, so it should be checked.
This in effect disables the faster atomic ops on msvc 7.1 and older, even if
only the MemoryBarrier() call is missing. But it ensures for the fist cut
that it will build everywhere. If somebody cares for msvc 7.1 enough and has
one for testing installed, he might provide the apropriate defines to guard
that MemoryBarrier() call.
I tested that msvc8 32/64bit still passes the configure tests and compiles.
"
implementation of the atomic increment and decrement into a implementation
file.
This way inlining and compiler optimization can no longer happen for these
implementations, but it fixes compilation on win32 msvc targets. I expect
that this is still faster than with with mutexes.
Also the i386 gcc target gets atomic operations with this patch. By using an
implementation file we can guarantee that we have the right compiler flags
available."
atomic related compile failures with msvs2005. Attached changes to make win32
really use the atomic stuff. There are pointer typecast problems and some
historic alignment restrictions that I just took from a previous similar
implementation of mine without looking deep enough. "
- 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
"Here is a collection of changes which should fix issues building the OSG with CMake 2.6.0 (along with some other changes)
CMakeLists.txt:
* Set CMP0003 to supress warning about linking against -lpthread (which is a
non-absolute library location). (CMake 2.6.x fix)
* Modified the WIN32_USE_MP and a couple of other Visual Studio specific flags
to be in an IF(MSVC) block (minor tweak to reduce exposing this stuff on MinGW builds)
* Includes my second set of glu tesselator autodetection changes that you
seemed to want but haven't committed yet.
src/OpenThreads/pthreads/CMakeLists.txt:
* Eliminates warning when compiling on Linux about spaces in link line (CMake 2.6.x fix)
CMakeModules/OsgMacroUtils.cmake:
* Tweaks to make the macros behave properly under CMake 2.6.0 (doesn't change behavior under CMake 2.4.x)
CMakeModules/Find3rdPartyDependencies.cmake:
* Adds the NO_DEFAULT_PATH option to all of the search options so that things in C:\Program Files\OpenSceneGraph aren't accidently picked up during configure time and instead only things in the "3rdParty" folder are discovered. (general bugfix)
"
post 2:
"Ok, hold the presses. I just discovered that for some odd reason the osgdb_* plugins under Linux aren't getting put under the osgPlugins-2.5.0 folder. Not exactly sure why this broke, the folder was there, just empty. I'll have to look into it this evening."
post 3:
"Fixed, was caused by the switch to CMAKE_LIBRARY_OUTPUT_DIRECTORY and some code in osgPlugins/CMakeLists.txt that effectively overrides LIBRARY_OUTPUT_PATH on non-MSVC compilers to dump the plugins in the plugins folder. I tweaked it to override CMAKE_LIBRARY_OUTPUT_DIRECTORY as well. Seems to work fine."
find libcurl. Mike's 3rdParty only has curllib.
I realize now that the in appended file I have earlier removed
searching for freetype219 since I have it but it will break the build
of osg."
This is caused by the OSG_MSVC_VERSIONED_DLL hack.
there are hard-coded paths to place the dll's in the bin /dir that normally would go
in the lib/config (release/debug) dirs. Nmake has different locations for the files (no config dir).
fix: change the macro's in OsgMacroUtils.cmake for the IF(NOT MSVC_IDE) situation.
Libs go in lib/, and DLLs and executables go in bin/
To accopmplish this for MSVC_IDE the targets get a "../../bin" prefix,
for nmake this should be "../bin" (because there are no config folders).
This fix mimics the behaviour of the MSCV_IDE (visual studio) build system when building with nmake.
Note:
A change in the main CMakeLists.txt creates the needed plugin directory in the binary dir.
see included files for the changes:
r7885fix-v2/CMakeModules/OsgMacroUtils.cmake
r7885fix-v2/osgWrappers/CMakeLists.txt
r7885fix-v2/CMakeLists.txt
The behaviour of visual studio projects (and other build systems) remain unchanged.
Tested building and installing with nmake and visual studio 8 debug and release.
"
contain better support for environmental variables to pre-empt the
autodection default search path order which is very helpful for people
who do automated builds. (I recommend that the remaining modules
consider adding the same system to make things consistent and easier
for those people that want to do the automated builds.)
The CMAKE_PREFIX_PATH has also been added to help people. I don't
recommend adding this to the other modules because it looks like CMake
agreed with my idea and will be adding the support in 2.6. So when
that ships, people will get it for free. (In the meantime, my modules
that do have it, it can be used.)
Finally, I've submitted all of these modules to official CMake plus
more so they will be in the next version of CMake. It looks like I may
need to sort some compatibility issues out with the KDE people who
seem to have conflicting modules, but this is unrelated to the updates
submitted here as OSG already has these conflicts. I figured I would
just sync OSG up with my current/best versions.
Also of note, I added the large batch of Findosg*.cmake modules to
CMake so people building against OpenSceneGraph can use these without
writing their own. I wasn't sure if I should submit them here or not
since they are for building against OSG and not for building OSG
itself. So they are not included.
"
File osgShadow/Version.cpp, Line 25:
const char* osgShaodowGetLibraryName()
should be:
const char* osgShadowGetLibraryName()
File CMakeModules/OsgMacroUtils.cmake, Line 224:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX})
should be:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}")
Otherwise setting CMAKE_DEBUG_POSTFIX to an empty string instead of "d" in
the main CMakeLists.txt does not work under Linux.
"
CmakeLists.txt and to the FindPerformer.cmake module.
Under Windows libs are: libpf.lib (we need to add the lib prefix) and
libpfdu-util.lib (libpfdu and libpfutil are compiled into one lib)
We need to add PFROOT to the search path for libs and includes (default
environment variable for Performer path)
And at last we need to put PFROOT/include and PFROOT/include/Performer
as include dir for compiling."
installed in /opt/local/include on my system (courtesy of DarwinPorts). I've added a CMakeModule to
look for zlib.h and the library in various places. The files are attached."
CMake doesn't recognize it properly on windows.
1) the header detection on a directory "freetype" fails, it seems to
need a filename: "ft2build.h" actually works.
2) the 3rdparty I am supplying for FlightGear contains freetype-2.3.4. I
added the correct library naming for this particular release.
I double-checked my directory layout with the 3rdparty supplied by other
OSG contributors."
according to the OpenSceneGraph/CMakeLists.txt and the include/osg/Version settings.
These changes mean that the 1.9.5 release will have a libs/osgPlugins-1.9.5 directory.
and the configuration file template use by the command is the second file.
The command use the cmake_install.cmake file which list all file installed by the install target.
this issue come from the CMake FAQ"
"
Here are more changes for the CMake scripts:
- I removed CMAKE_INSTALL_PREFIX in FindOpenThreads as a follow up to
the discussion thread.
- I introduced an experimental CMAKE_PREFIX_PATH to replace it.
- I added CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, and
CMAKE_LIBRARY_PATH to the CMake GUI so users can enter values there
instead of in the environment.
- I added OPENSCENEGRAPH_*_VERSION variables (MAJOR, MINOR, PATCH).
These should be kept up-to-date with the real version numbers. Mac
bundles like to have version information so users can find out the
version they are running through standard About panels and also
automated system reporters for troubleshooting/bug tracking. In
theory, this information could be used for library versioning.
We should do the same for OpenThreads, but I forgot about it.
- I added some Mac Info.plist stuff (which uses the version information).
"
"These enhancements make it much easier to control which libraries get
found by FIND_ using environmental variables. The problem with the old
script was that CMake searches what it considers system paths first.
This makes it difficult to override in the case where you might have a
stable version in /usr/local, but are trying to build a bleeding edge
release in the non-standard location /bleeding-edge.
I went to the CMake mailing list hoping to find a good solution to
this. Unfortunately, there isn't one, and I have to do something
rather bone-headed in the Find module. Basically, I have to run FIND_
twice: once with default search paths turned off and my environmental
variables listed, and again with standard search paths reenabled. At
least it works.
I also added a few more environmental variables, specifically:
OPENTHREADS_INCLUDE_DIR
OPENTHREADS_LIBRARY_DIR
These two variables address the shortcoming of OPENTHREADS_DIR in the
case where the include path and library path don't share a common
parent.
Put all this together, and you can setup an automated shell script or
Microsoft .bat file to configure and build your application in an
automated step.
You still should be able to use the key CMake variables like
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will
occur after the environmental paths are searched. The reason for this
is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are
more specific. This prevents the accidental ordering problem where you
might use CMAKE_INCLUDE_PATH to find some other component like GLUT,
but didn't want to accidentally include an older version of
OpenThreads located in the same area.
As the ultimate override, you can still pass -DVAR=value arguments to
cmake and it will take these above all else. However, it's safer for
people to not use these in case we modify the script and change the
variable names.
Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX}
searches in the Find module. As I've said before, this is kind of a
hack and the variable wasn't really intended to be used in this way.
And I just got bitten by it in some bad corner cases. The problem is
that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake
sets a default value for it (such as /usr/local). The problem is that
/usr/local may not be the place you want searched. If you wait to set
the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already
run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to
change the value in the GUI, it's too late if you had a stuff in
/usr/local because FIND_ already found something and won't change the
value when you reconfigure since it is already set. You will have to
manually change the value yourself. Furthermore, as another problem
example, on the Mac, /Library/Frameworks is supposed to be searched
before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in
/usr/local to be hit first which took me a really long time to
understand how this was happenning. The work around is that I must
push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to
conflict with anything else. But I think it would be much better if we
removed it entirely.
And with so many different environmental variables at our disposal, I
don't think we need this one:
(Checked by CMake automatically:)
CMAKE_INCLUDE_PATH
CMAKE_SYSTEM_INCLUDE_PATH
CMAKE_LIBRARY_PATH
CMAKE_SYSTEM_LIBRARY_PATH
PATH
LIB
(Checked by us:)
OPENTHREADS_INCLUDE_DIR
OPENTHREADS_LIBRARY_DIR
OPENTHREADS_DIR
OSG_INCLUDE_DIR
OSG_LIBRARY_DIR
OSG_DIR
"
a bug regarding when to set the debug version. It waited until both
include and library were set, but it shouldn't wait on include.
Also added a fix to the optional warning flags."
"Attached is a patch allows access access to the CMake MACOSX_BUNDLE
option. Now SETUP_APPLICATION and SETUP_EXAMPLE take an additional
optional parameter that specifies if the program is a command line
application or a GUI application (think: IS_COMMANDLINE_APP). Passing
1 means true (is_commandline_app). Passing 0 or omitting the parameter
means false.
I changed the scripts for osgversion and osgunittests to support this
option because I believe they are command line apps. Are there any
others?"
It should not be introusive to any other palatform apart MSVC, but in order to link to debug-specific libs
I had to change plugins CMakeLists to differentiate debug/release linkage, I have used the same macro used in core libs
Now the macro used for plugin and examples linking test for existance of TARGET_LIBRARIES_VARS
that holds the names of the variables that have to be used for linking"
so I' ve set up a macro that uses the variable name expanded for linking, and test if a variable ${LINK_VAR_NAME}_DEBUG
like OPENTHREADS_LIBRARY_DEBUG exists and in case uses it for linking in debug mode.
I' ve also set up FindOpenThreads to set up these variables.
I had to edit the core libraries CMakeLists to add the calls to the macros used.
I' ve tested under MSVC"
