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