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

[Edward d'A. <tru...@gm...>]

On 27 November 2016 at 11:53, Durk Talsma <dur...@gm...> wrote:
> 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.

I noticed the same problem.  I have been implementing a test suite
infrastructure using CppUnit for flightgear itself (not simgear) as
part of my FGPythonSys experiments [1], and noticed that
modularisation is problematic due to the dependency of globals and
everything that then brings in.  I wonder if coming up with a way of
breaking the dependency on globals.hxx - passing the data structure
(or a mimic in the case of a functional test) into the subsystem using
the new subsystem infrastructure, using property subtrees and
synchronisation, etc. would allow the subsystems to be truly
independent.  For FGPythonSys [2], I simply passed in the data
required to eliminate the globals dependence in fg_init:

#ifdef HAVE_PYTHON
    ////////////////////////////////////////////////////////////////////////
    // Initialize the Python interpreter.
    ////////////////////////////////////////////////////////////////////////

    if (fgGetBool("/sim/startup/python-enabled", true)) {
        FGPythonSys* python = new FGPythonSys();
        globals->add_subsystem("python", python, SGSubsystemMgr::INIT);
        python->setPropertyTree(globals->get_props());
        python->setRoot(globals->get_fg_root().utf8Str());
        python->init();
        SG_LOG(SG_GENERAL, SG_INFO, "Python init took:" << st.elapsedMSec());

    // Disabled by the user.
    } else
        SG_LOG(SG_GENERAL, SG_ALERT, "Embedded Python interpreter disabled.");
#endif

Regards,

Edward


[1]  https://sourceforge.net/u/edauvergne/flightgear/ci/cppunit/r6/~/tree/
https://sourceforge.net/u/edauvergne/simgear/ci/cppunit/r5/~/tree/

[2] https://sourceforge.net/u/edauvergne/flightgear/ci/python/r9/~/tree/
https://sourceforge.net/u/edauvergne/simgear/ci/python/r6/~/tree/
https://sourceforge.net/u/edauvergne/fgdata/ci/python/r4/~/tree/