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/
