According to the discussion around [1], using the system CppUnit library
is rarely useful but likely to cause problems (due to possible
incompatibilities between versions); that is, unless people doing so
really know what they are doing. For this reason, this commit changes
the CMake config logic as follows: the system CppUnit library is now
only used when explicitly asked for with -DSYSTEM_CPPUNIT=ON on the
CMake command line.
[1] https://sourceforge.net/p/flightgear/mailman/message/36636483/
When CMAKE_BUILD_TYPE is Debug and we are compiling with GCC, add the
following options to CMAKE_C_FLAGS and CMAKE_CXX_FLAGS:
-O0 -fno-omit-frame-pointer -fno-inline
Ditto for Clang, except that -fno-inline-functions is used instead of
-fno-inline.
cf. thread starting at
https://sourceforge.net/p/flightgear/mailman/message/36295412/
This allows for finer control of the test suite execution. The default of ON
will cause the test-suite to be executed after compiling the test_suite target.
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 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.
Also build the test code first, so tests can reside in source tree as
well as the test tree.
Finally, build local Sqlite with -fpic to give consistent linkage when
using either built-in or system sqlite.
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
