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