flt files are missing. I'm not sure if it was intentionally removed from the project, so I left the everything in place, but removed the target from the build aggregate targets so it doesn't get in the way of the build system.
Added back osgTerrain to the project (don't know who deleted those). SDL's aggregate target is also missing.
"
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).
"
return the length of the stream.
Implemented the virtual methods in QuicktimeImageStream, (getLength,
getReferenceTime, setTimeMultiplier), to return valid value for each.
"
a collegue of mine noticed that on Windows and X11 the modifier state (such as
Alt or Ctrl) would be applied one key press too late: e.g. press & hold Alt,
press a, release Alt, press a, press a would generate the key sequence a,
Alt-a, a instead of Alt-a, a, a.
The problem is also present on Carbon. Moving the call to setModKeyMask in
front of the call to keyPress fixed it for me on Carbon and X11. I suppose
that this will fix the problem for Windows as well."
"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
"
I was using ${FOO_CONFIG_HAS_BEEN_RUN_BEFORE} instead of just
FOO_HAS_BEEN_RUN_BEFORE.
In this case, it happened to work out to still be correct, but in
general it shouldn't have the ${}. (I really hate this syntax.)"
