Getting into FG OSG with CMake

|- CMake -|- OSG -|- Ready -|- Build -|- Downloads -|- End -|

I had been building my own MSVC8 solution files for components of OSG, and including them in my SINGLE SOLUTION FILE - see previous, but here decided to try the 'make' utility OSG recommend ... that is, CMake - see - - the cross-platform, open-source make system. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice, and that includes MSVC8.


I did two (2) things -

1. Downloaded the full source using CVS - set CVSROOT=<folder-of-your-choice>, and using the CVS instructions from the CMake download page -
Respond with password cmake -
cvs -d login
Follow this command by checking out the source code:
cvs -d co CMake
This will download the full source to a folder named CMake. This is in the event I want to build CMake myself ... but for now I choose to -

2. Downloaded the CMake Windows Installer -

Windows (Win32 Installer)

cmake-2.4.6-win32-x86.exe (check for later version!)

This installer ran smoothly, and I had a new GUI program item available -
New CMake program item
During the install, you are asked if you want a path to CMake added, so you can also run it as a command line tool.



From the OSG site -> Documentation -> Getting Started, it looks very simple ...

(a) Downloading OpenSceneGraph - I used SVN to check out the development version of OSG ... since I had already done this, I just changed into the folder and used 'svn up', to get a full update of the latest (20070523).

(b) Downloaded the 3rdParty_Win32binaries, namely -
23/05/2007 16:31 7,237,421

I NEVER use the SVN download/update folder for building. I always copy the FULL SOURCES to another folder, in this case - C:/FG/17

I used my powerful setupfg.bat batch file to copy ALL the SVN/CVS sources into appropriate folders, but this requires that ALL the sources are arranged per my source folder setup. Inside that folder, the batch file created an OpenSceneGraph folder, filled with the copied SVN source. And I unzipped the 3rd Party zip, into the same C:/FG/17 folder, creating a 3rdParty folder.

in the NEW C:/FG/17 folder -
Work folders, including 3rdParty folder


Ready For The CMake Build

Wow, it could not have been simpler! As the OSG web site states -
1. Launch CMake from the start menu.
2. Drag and drop OSG CMakeLists.txt into the frame.
3. Click 'Configure' and choose your compiler/IDE. I had to do this twice to get the 'Ok' to un-grey!
4. Fill in, if any, missing mandatory fields - CMake pops up an 'Error' dialog in the configuration process if something went wrong. Click 'Configure' again. I had none ;=))
5. Click 'Ok' or 'Generate'.

And a MSVC8 solution file, and the project files (138!) were generated. Loading this OpenSceneGraph.sln into MSVC8, and pushing build (F7), built the 67 projects without a hitch. That was Debug. Switching to Release, and the second set was generated with ease.

In almost no time at all, I had some 118 OSG DLL (shared libraries) built! Ready for the following full build of FlightGear, using my SINGLE SOLUTION FILE ...


Build FlightGear

I downloaded my, and deleted all the OSG projects from it before unzipping it into the new C:/FG/17 folder. Of course, on loading the fgfs/fgfs.sln file, it complained that the 'osg' components were missing, and I deleted the osg items that were marked 'not available'. The later version of this SINGLE SOLUTION FILE is below,

For the link I had to add osgViewer.lib to the Release, and osgViewerd.lib to the Debug, and amend the library path to
..\OpenThreads\lib\$(IntDir); and I was away. I had built, and linked FlightGear.exe (and FlightGearD.exe) in no time at all ...

Adjusting my upd.bat to also copy ALL the OSG DLL files to the bin folder, I started FlightGear.exe, and IT FLEW! As now becoming usual, I got a frame rate in the high 80-90 fps range, and with no 'warning' messages ;=)) Maybe I can delete some of the DLL files, to see exactly which one brings back the 'warnings', so I can exactly know what to add to the original project ... but that can wait for another day.

This leaves me in a quandary. Do I try to continue with my SINGLE SOLUTION FILE, or, at least, leave OSG to CMake and MSVC8 separately? It seems such a short and easy step to use CMake to dynamically generate the MSVC8 solution files, and has the distinct advantage of taking care of the ever changing OSG sources ... Maybe, with some effort and understanding of CMake, I could get it to build the full, all sources, SINGLE SOLUTION FILE ;=)) but this is too ambitious for today ...



The runtime and the solution files, excluding OSG, which is now built with CMake

24/05/2007 Single MSVC8 solution, excl OSG * 63,470 3348492d920fc81d9732e14abfad0829
24/05/2007 Runtime EXE and DLL - MSVC8 * 5,142,748 e3fe83c06614ef9fa9796964935f0a4e

* Note: These two(2) zips were redone 15/06/2007, so have this date.


Geoff R. McLane
email address
May 24, 2007.

EOP - Devel-04.doc.


checked by tidy  Valid HTML 4.01 Transitional