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