Avoid encoding test-data as strings, since this exceeds MSVC limits
on string literals, and tests don’t need to be relocatable anyway,
so we can just hard-code the source location into config.h
This was intended to only affect Debug builds, but when using a multi-
config generator (XCode, Visual Studio etc) it affects all builds.
Disabling for now until we figure out a better way to do this.
Avoid the need to set PKG_CONFIG_PATH externally, use the internal
CMake behaviour where CMAKE_PREFIX_PATH is added. Unfortunately, we
do still need to manually add CMAKE_INSTALL_PREFIX, which is not
auto-added.
making the build between Simgear and Flightgear consistent.
- Fix an issue with lib/lib64 path between CentOS/RedHat distributions
and Debian derived distributions.
- Fix a compilation issue with HLA in the Flightgear code.
The test suite CMake target variables have been shifted back into
test_suite/CMakeLists.txt. These are now correctly constructed and placed into
the parent scope where the test_suite target now resides.
The add_custom_target() CMake function for the test_suite target has been
shifted from test_suite/CMakeLists.txt to the top level CMakeLists.txt file.
The variable setting CMake code required for this has also been shifted. This
allows for the same build command 'cmake --build . --target test_suite' to work
on all operating systems.
This is necessary on macOS where DBus is typically installed using
Homebrew, and hence we need additional linker flags to find the
library. Using the PkgConfig::DBUS imported target handles all this
transparently, but then we need to define an imported target for
Windows to work.
- When FGDATA_SRC_DIR isn't explicitly set by the user, set it to
${PROJECT_SOURCE_DIR}/../fgdata if this is a directory.
- When TRANSLATIONS_SRC_DIR isn't explicitly set by the user, look for
translations in ${FGDATA_SRC_DIR}/Translations instead of
${PROJECT_SOURCE_DIR}/../fgdata/Translations (i.e., honor the setting
of FGDATA_SRC_DIR for the sake of translation lookup).
This fixes the problem explained in [1] and [2].
[1] https://sourceforge.net/p/flightgear/mailman/message/36645499/
[2] b2274fbbed/
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.
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
