[Flightgear-devel] RFC: Improving FlightGear's modularity

[Durk T. <dur...@gm...>]

Hi all,

After a couple of weeks of exploring how I can best approach setting up the
new traffic system, I feel I've gotten to the point where I need some
advice. I'm either missing something very obvious, or I'm trying the
impossible...

To make a long story short, I'm trying to reuse FlightGear's AI and Traffic
code in a separate application that feeds traffic data to FlightGear via
the multiplayer system. For this, I've set up a new target under
flightgear/utils/traffic. It's my intention that this program reuses
existing subsystems with only a minimum of code duplication.

If I recall correctly, in the old autoconf days, a static library would be
build for each subdirectory, so that -in theory- it should be possible to
link a subsystem by using a linker directive; i.e. -ltraffic -lairports
-navaids, etc. With the CMakeFile system, I've not yet been able to find
out how to do this. Therefore, I've tried a couple of other approaches,
each of which apparently ends in a dead end street. I'm sure something like
this is possible, and I'm probably just missing the obvious. So my first
question is: How can I link to existing libraries?

The main alternative approach I tried is to directly include all the
required cxx files into the target's CMakeFile; i.e.,

set(SOURCES,
     fgtraffic.cxx
     ../../src/Traffic/TrafficMgr.cxx
     ../../src/Traffic/Schedule.cxx
     ../../src/Traffic/SchedFilght.cxx
     )

Although this might work, I see two main problems with this approach: 1)
the fgfs target may require different compiler directives than those set by
the fgtraffic target, so that the source files get build incorrectly
(because, if I understand the build logic, compilation is only done once,
based upon the first target that is processed); 2) I'm entering an endless
cascade of dependencies, resulting eventually in almost the entire
FlightGear codebase being included.

In addition to the question I asked above, there's a related issue that I
wanted to bring up for discussion. The current FlightGear code seems messy
 with respect to interdependencies (no offence intended; I know that the
code has a long history): For example, The traffic manager depends on
globals (which in itself requires more than half of the FlightGear code
base to be included) the AIModels subsystem, and Airports. The airports
code, in turn depends on the Navaids code, scenery, the ground cache, etc.
In sum, each of these systems depend in turn on a host of lower level
system.

Maybe there simply isn't a way to cleanly reuse existing code from
FlightGear without bloating my traffic utility, in which case I probably
will focus on reimplementing existing functionality. Before I do so,
however, I would like to hear some opinions on whether it would be possible
to improve the modularity of FlightGear's code.

Cheers,
Durk