Melchior FRANZ wrote:
> If your argument would have been that we want shared libs (which we
> clearly didn't want in the past), then there'd be something to discuss.
I know that shared libs are not wanted here, so I was not going to
propose them.
> But if it's only about developers wasting less disk space when they
> have binaries linked against all available windowing libs on their
> disk, then I must say it's totally pointless.
It is also about having to run "configure && make && make install" one
time instead of three times. That is at least inconvenient to type (or
requires more or less intelligent wrapper scripts), but it also takes
about three times as long to compile.
Tedious, error-prone.
OK, I have an additional proposal:
1. Build and install one "fgfs" binary as current CVS does, but
internally using libGUI-FOO.a and libMain-FOO.a instead of plain
libGUI.a and libMain.a, chosing the FOO by the same logic as we
are currently chosing it.
2. Give the option to run
$ make -C src/Main fgfs-{glut,SDL,osgViewer}
to specifically build the three. As the executables are linked
statically, the developer can run them from the build directory
without installing them.
This would remove any concerns about symlinks, and require no
change to configure's --enable-foo options.
(Implementation using EXTRA_PROGRAMS and EXTRA_LIBRARIES)
Tim Moore has proposed to rewrite the fg_os interface as an abstract
base class and then have three classes providing the -glut, -SDL,
-osgViewer version. That part of the operation would definitely be
feasible and would also allow one binary and chosing at runtime.
However, src/GUI/libGUI.a is linked against plib - and plib choses at
compile time which backend it will use. FG CVS does that via AC_DEFINEs
in configure.ac (PU_USE_GLUT, PU_USE_SDL, PU_USE_NATIVE), i.e. via
#defines in config.h.
For compiling libGUI-FOO.a, one can just use the proper
libGUI-FOO_a_CPPFLAGS definitions, but having all three libGUI-FOO.a
statically linked to the same executable for the "chose-at-runtime"
scenario will almost certainly not work.
-------------------------------------------------------------------------
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
