FG/OSG currently offers to build the "fgfs" binary as one of three
different versions:
a) Using glut
b) Using SDL
c) Using osgViewer
As the whole thing is still in development, it makes sense for
developers to have more than just one of the three, so that one can
compare their behaviours.
The current solution in CVS requires:
1. One FlightGear source tree (35MB)
2. One FlightGear build tree per "fgfs" version (ca. 200MB each)
I.e. run "configure && make && make install" thrice.
3. One statically linked "fgfs" installed binary per version
in its own ${prefix}
(more than 55MB each)
${prefix_glut}/bin/fgfs
${prefix_SDL}/bin/fgfs
${prefix_osgViewer}/bin/fgfs
Total is about 800MB for the CVS solution.
That looked a little much to me, so I changed the FG build system to
optionally create all three binaries from one build tree. That changed
things to about
1. One FG source tree (35MB)
2. One FG build tree with three binaries (300MB)
Run "configure && make && make install" once.
3. Three statically linked binaries installed: (150MB)
${prefix}/bin/fgfs-{glut,SDL,osgViewer}
${prefix}/bin/fgfs -> symlink to fgfs-foo
Total: About 500MB for the statically linked solution.
That still looked a little much to me a little much, so I switched to
dynamic linking using libtool.
1. One FG source tree (35MB)
2. One FG build tree (200MB)
Run "configure && make && make install" once.
3. Three dynamically linked fgfs binaries installed (10MB each)
${prefix}/bin/fgfs-{glut,SDL,osgViewer}
${prefix}/bin/fgfs -> symlink to fgfs-foo
4. A number of dynamically linked FG internal libraries (55MB total)
${prefix}/lib/FlightGear-0.9.10/li*.so
Total: About 320MB for the dynamically linked solution, i.e. much less
than half the original size.
I can see that introducing libtool will cause problems for many ancient
systems, so I won't dare propose the dynamically linked solution for
committing to CVS.
However, the statically linked solution might be interesting. Things to
figure out about it are:
1. What should the command line interface for configure look like?
In CVS:
./configure
build glut version
./configure --enable-sdl
build SDL version
./configure --enable-osgviewer
build osgViewer version
2. Should one keep the option of building the same fgfs binary we
are building today, or make a symlink to one of the built fgfs-foo
binaries the default?
3. Will creating a symlink "fgfs" to one of the three "fgfs-glut",
"fgfs-SDL" and "fgfs-osgViewer" be problematic, e.g. on systems
which do not support symlinks?
I can do the proper patch when I know what has a chance to be committed.
Comments?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
