The CppUnit source is built as a static library and linked to the run_test_suite
executable. The FlightGear CppUnit library is now build using CMake rather than
using the Autotools build system.
This required many time related include files, functions, and variables to be
tested for via CMake, and converted to macros via #cmakedefine, so that they
would be automatically set for the test-mktime.cxx file.
This old standalone test, from Curt back in 2001, was converted to the format
required for the CppUnit test suite. As most of simgear/math/sg_geodesy.hxx no
longer exists, the code was updated using SGGeod and SGGeoc. Hardcoded values
are used to permanently lock in the values currently calculated by simgear.
Each of the global logstream priorities are captured into its own
std::ostringstream stream, all held together in the test suite global _iostreams
class instance. This object can be obtained by calling getIOstreams(). The
streams are captured using the StreamLogCallback class, which is a simple
modification of the simgear FileLogCallback class, registered with the global
logstream's addCallback() function.
When tests fail, all of contents the different simgear logstreams are now
reported. The failure report consists of the following sections:
- Failure information.
- SG_BULK simgear logstream (all messages).
- SG_BULK only simgear logstream.
- SG_DEBUG only simgear logstream.
- SG_INFO only simgear logstream.
- SG_WARN only simgear logstream.
- SG_ALERT only simgear logstream.
- Combined STDOUT and STDERR streams.
Any empty sections, except for SG_BULK, will not be shown.
A large number of improvements have been made by subclassing the CppUnit classes
and overriding the base functions, including CompilerOutputter, TestListener,
and TextTestRunner. All IO has also been captured by the test runner.
The result is that during the test suite run, only the characters '.', 'F', and
'E' are output for a pass, failure and error state. At the end of each test
suite category, all failures and errors are reported in full detail, including
the different captured IO streams. A final synopsis is printed out, improving
the overview in the case of too many tests failing.
For the fgCompilerOutputter class, the printSuccess(), printFailureReport(),
printFailureDetail(), and printSuiteStats() functions have been replaced to
implement the above printout design. The class also stores the std::vector of
TestIOCapt structures for the final printouts.
The fgTestListener class handles the events from the running of the test suite.
The startTest() and endTest() functions are used for IO capture. The IO is
placed into a TestIOCapt data structure, with one std::string for holding the
combined STDOUT and STDERR IO, and another for the SG_LOG IO. If failures
occur, the TestIOCapt structure is appended to the fgCompilerOutputter vector.
The startTest() and endTest() functions are also used for starting and stopping
a timer to allow the full test suite to be timed. And the addFailure() function
simply registers test failures or errors.
The fgTestRunner class overrides the CppUnit::TextTestRunner::run() function,
simply to prevent the base method from spawning a second test listener, causing
the test output to be duplicated.
Some auxiliary formatting functions have been added to print out titles,
sections, and synopsis summary lines.
This includes the basic CMake infrastructure for building and executing the test
suite. Four test categories have been added - unit, system/functional, GUI, and
simgear unit tests. The test suite is run by typing 'make test_suite'.
All of the fgfs sources are included in the new run_test_suite executable,
excluding the bootstrap routine and its main() function. The test suite
currently consists of a single dummy unit test for the NasalSys subsystem, and a
single demonstration simgear/props unit test.
Since the new _storagePath data member internally contains the add-on
id, changing _id after _storagePath has been initialized would make both
data members inconsistent. As changing the add-on id is probably not a
very useful operation, the simplest way to prevent such an inconsistency
from happening is to make Addon's _id data member const (as is already
the case for _storagePath), and thus remove Addon::setId().
Consequently, remove the Addon default constructor too, since add-ons
with an empty id would be ill-formed and couldn't be changed (_id being
const now). This leaves us with one Addon constructor:
Addon(std::string id, AddonVersion version = AddonVersion(),
SGPath basePath = SGPath(), std::string minFGVersionRequired = "",
std::string maxFGVersionRequired = "",
SGPropertyNode* addonNode = nullptr);
New methods Addon::createStorageDir() and Addon::getStoragePath() with
corresponding Nasal bindings in the addons.Addon ghost:
createStorageDir() method (returns the dir, doesn't fail if it already
exists)
storagePath read-only attribute to get the dir
The directory reserved for each add-on is
$FG_HOME/Export/Addons/ADDON_ID, but please use the above methods (or
the corresponding C++ ones) to avoid hardcoding such paths in your code.
Also create directory $FG_HOME/Export/Addons in fgInitConfig() as a way
of reserving the namespace, in order to prevent future failures in case
someone would have the strange idea to create it as a file...
It is the call to exit that causes FG to lock up and become a zombie.
Alternative is to throw an exception, i.e.:
throw sg_error(std::string("YASim SOLUTION FAILURE:") + a->getFailureMsg(););
This adds the fix for non converging aircraft. Henning has performed a thorough analysis of all of FGAddon and other repositories and there are a few models that fail, however there have always been a few that fail - but with this patch this situation is improving.
As for aircraft, an add-on can now add its custom dialogs in
$addon_dir/gui/dialogs. This commit makes NewGUI consider this directory
as a dialog-providing one for each registered add-on.
If an add-on has a file named addon-menubar-items.xml in its base
directory, load it and add its items to the FG menubar.
Logically, fgStartNewReset() should call
flightgear::addons::AddonManager::instance()->addAddonMenusToFGMenubar()
in order to re-add the items, however doing so would cause the
add-on-specific menus to be added one more time on every reset, because
for some reason, commit 45ea8b5daa added
the PRESERVE attribute to /sim/menubar (apparently to preserve the state
of menu entries upon reset?).
Note: the addon-menubar-items.xml files are reloaded during reset,
however the menu bar doesn't reflect this, since adding the
reloaded items to the menu bar in fgStartNewReset() would cause
the add-on-specific menus to appear several times in the menu bar,
as explained above.
