fly/flightgear
1
0
Fork 0
Code Activity
flightgear/tests/CMakeLists.txt

136 lines
3.9 KiB
Text
Raw Normal View History

Partial testing framework. 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.
2017-03-21 20:43:42 +00:00
set(sources
Main/options.cxx
Main/fg_commands.cxx
Main/fg_props.cxx
Main/globals.cxx
Main/locale.cxx
Main/util.cxx
Unit-test for initPosition. Only basic, but can be expanded incrementally now
2017-03-27 14:37:54 +00:00
Main/positioninit.cxx
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface This commit adds C++ classes for add-on management, most notably AddonManager, Addon and AddonVersion. The AddonManager is used to register add-ons. It relies on an std::map<std::string, AddonRef> to hold the metadata of each registered add-on (keys of the std::map are add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>). Accessor methods are available for: - retrieving the list of registered or loaded add-ons (terminology explained in $FG_ROOT/Docs/README.add-ons); - checking if a particular add-on has already been registered or loaded; - for each add-on, obtaining an Addon instance which can be queried for its name, id, version, base path, the minimum and maximum FlightGear versions it requires, its base node in the Property Tree, its order in the load sequence, short and long description strings, home page, etc. The most important metadata is made accessible in the Property Tree under /addons/by-id/<addon-id> and the property /addons/by-id/<addon-id>/loaded can be checked or listened to, in order to determine when a particular add-on is loaded. There is also a Nasal interface to access add-on metadata in a convenient way. In order to provide this metadata, each add-on must from now on have in its base directory a file called 'addon-metadata.xml'. All this is documented in much more detail in $FG_ROOT/Docs/README.add-ons. Mailing-list discussion: https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 12:58:14 +00:00
Add-ons/Addon.cxx
Add-ons/AddonManager.cxx
Add-ons: move parsing of the metadata file to a separate translation unit This will be tidier, esp. since I am going to introduce another XML config file.
2018-01-05 15:40:11 +00:00
Add-ons/AddonMetadataParser.cxx
Add-ons: add a simgear::ResourceProvider for add-on-specific lookup A resource can be specified with the syntax: [addon=ADDON_ID]relative/path Such a resource corresponds to the file $addon_base_path/relative/path for the specific add-on whose identifier is ADDON_ID. If the particular add-on isn't registered, looking up such a resource throws sg_exception.
2018-01-09 23:17:22 +00:00
Add-ons/AddonResourceProvider.cxx
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface This commit adds C++ classes for add-on management, most notably AddonManager, Addon and AddonVersion. The AddonManager is used to register add-ons. It relies on an std::map<std::string, AddonRef> to hold the metadata of each registered add-on (keys of the std::map are add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>). Accessor methods are available for: - retrieving the list of registered or loaded add-ons (terminology explained in $FG_ROOT/Docs/README.add-ons); - checking if a particular add-on has already been registered or loaded; - for each add-on, obtaining an Addon instance which can be queried for its name, id, version, base path, the minimum and maximum FlightGear versions it requires, its base node in the Property Tree, its order in the load sequence, short and long description strings, home page, etc. The most important metadata is made accessible in the Property Tree under /addons/by-id/<addon-id> and the property /addons/by-id/<addon-id>/loaded can be checked or listened to, in order to determine when a particular add-on is loaded. There is also a Nasal interface to access add-on metadata in a convenient way. In order to provide this metadata, each add-on must from now on have in its base directory a file called 'addon-metadata.xml'. All this is documented in much more detail in $FG_ROOT/Docs/README.add-ons. Mailing-list discussion: https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 12:58:14 +00:00
Add-ons/AddonVersion.cxx
Add-ons: detailed, machine-parseable metadata for authors and maintainers (everything described here lives in the namespace flightgear::addons) New classes: Author, Maintainer, and Contact. Author and Maintainer derive from Contact. For each contact, the following can be defined in addon-metadata.xml: name, email, and url. See [1] for details about the syntax and usage policy. Nasal bindings have been updated accordingly, there are three new ghosts: addons.Contact, addons.Author and addons.Maintainer. The enum class UrlType has two new members: author and maintainer. The Addon::getUrls() method has a new signature: std::multimap<UrlType, QualifiedUrl> getUrls() const; because non-empty 'url' fields for authors and maintainers contribute to the result, and there can be an arbitrary number of authors and an arbitrary number of maintainers defined for a given add-on---therefore, std::map can't be used anymore. Finally, QualifiedUrl has a new field (detail) which stores the author name (resp. maintainer name) when the QualifiedUrl type is UrlType::author (resp. UrlType::maintainer). Currently, this 'detail' field is not used for other URL types, but this could be changed if desired. [1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 09:07:49 +00:00
Add-ons/contacts.cxx
Add-ons: move exceptions to their own translation unit
2017-12-14 08:28:11 +00:00
Add-ons/exceptions.cxx
Partial testing framework. 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.
2017-03-21 20:43:42 +00:00
Aircraft/controls.cxx
Aircraft/FlightHistory.cxx
Aircraft/flightrecorder.cxx
Aircraft/replay.cxx
Autopilot/route_mgr.cxx
Airports/airport.cxx
Airports/airport.hxx
Airports/apt_loader.cxx
Airports/airportdynamicsmanager.cxx
Airports/airportdynamicsmanager.hxx
Airports/dynamicloader.cxx
Airports/dynamics.cxx
Airports/xmlloader.cxx
Airports/runwaybase.cxx
Airports/pavement.cxx
Airports/parking.cxx
Airports/groundnetwork.cxx
Airports/gnnode.cxx
Airports/runways.cxx
Airports/runwayprefs.cxx
Airports/runwayprefloader.cxx
ATC/CommStation.cxx
# ATC/GroundController.cxx
# ATC/atc_mgr.cxx
Environment/atmosphere.cxx
Environment/environment.cxx
Environment/environment_mgr.cxx
Environment/environment_ctrl.cxx
Environment/presets.cxx
Environment/gravity.cxx
Environment/ridge_lift.cxx
Environment/magvarmanager.cxx
Navaids/airways.cxx
Navaids/fixlist.cxx
Navaids/markerbeacon.cxx
Navaids/NavDataCache.cxx
Navaids/navdb.cxx
Navaids/navlist.cxx
Navaids/navrecord.cxx
Navaids/poidb.cxx
Navaids/procedure.cxx
Navaids/positioned.cxx
Navaids/PositionedOctree.cxx
Navaids/routePath.cxx
Navaids/route.cxx
Navaids/waypoint.cxx
Navaids/FlightPlan.cxx
Navaids/LevelDXML.cxx
Network/HTTPClient.cxx
Time/TimeManager.cxx
Time/bodysolver.cxx
Scripting/NasalSys.cxx
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface This commit adds C++ classes for add-on management, most notably AddonManager, Addon and AddonVersion. The AddonManager is used to register add-ons. It relies on an std::map<std::string, AddonRef> to hold the metadata of each registered add-on (keys of the std::map are add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>). Accessor methods are available for: - retrieving the list of registered or loaded add-ons (terminology explained in $FG_ROOT/Docs/README.add-ons); - checking if a particular add-on has already been registered or loaded; - for each add-on, obtaining an Addon instance which can be queried for its name, id, version, base path, the minimum and maximum FlightGear versions it requires, its base node in the Property Tree, its order in the load sequence, short and long description strings, home page, etc. The most important metadata is made accessible in the Property Tree under /addons/by-id/<addon-id> and the property /addons/by-id/<addon-id>/loaded can be checked or listened to, in order to determine when a particular add-on is loaded. There is also a Nasal interface to access add-on metadata in a convenient way. In order to provide this metadata, each add-on must from now on have in its base directory a file called 'addon-metadata.xml'. All this is documented in much more detail in $FG_ROOT/Docs/README.add-ons. Mailing-list discussion: https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 12:58:14 +00:00
Scripting/NasalAddons.cxx
Partial testing framework. 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.
2017-03-21 20:43:42 +00:00
Scripting/NasalCondition.cxx
Scripting/NasalAircraft.cxx
Scripting/NasalString.cxx
Scripting/NasalPositioned.cxx
Scripting/NasalPositioned_cppbind.cxx
Scripting/nasal-props.cxx
Scripting/NasalSGPath.cxx
Scripting/NasalHTTP.cxx
Viewer/view.cxx
Viewer/viewmgr.cxx
)
foreach(s ${sources})
set_property(DIRECTORY APPEND PROPERTY fgtestlib_sources "${CMAKE_SOURCE_DIR}/src/${s}")
endforeach()
set_property(DIRECTORY APPEND PROPERTY fgtestlib_sources "${CMAKE_SOURCE_DIR}/3rdparty/cjson/cJSON.c")
get_property(fgtestlib_sources DIRECTORY PROPERTY fgtestlib_sources)
add_library(fgtestlib SHARED ${fgtestlib_sources}
unitTestHelpers.cxx
testStubs.cxx
fake_sgSky.cxx
fake_sgPrecipitation.cxx
fake_sound.cxx)
set_target_properties (fgtestlib
PROPERTIES
COMPILE_DEFINITIONS "FG_TESTLIB"
)
Test suite: add GPerfTools and system SQLite linking fixes If GPerfTools and/or the SYSTEM_SQLITE options are enabled, the test suite fails to build (GPerfTools is not linked explicitly in CMakeLists.txt, but becomes required by SimGear, so the linker failes with an "undefined reference" error; the SQLite library the test suite links against is always hardcoded to the FG-provided one). This patch adds the GPerfTools library to the target link libraries (if the profiler is enabled) and links to the system SQLite library whenever SYSTEM_SQLITE is enabled.
2017-03-26 10:10:15 +00:00
if(FG_HAVE_GPERFTOOLS)
Unit-test for initPosition. Only basic, but can be expanded incrementally now
2017-03-27 14:37:54 +00:00
target_include_directories(fgtestlib PRIVATE ${GooglePerfTools_INCLUDE_DIR})
Test suite: add GPerfTools and system SQLite linking fixes If GPerfTools and/or the SYSTEM_SQLITE options are enabled, the test suite fails to build (GPerfTools is not linked explicitly in CMakeLists.txt, but becomes required by SimGear, so the linker failes with an "undefined reference" error; the SQLite library the test suite links against is always hardcoded to the FG-provided one). This patch adds the GPerfTools library to the target link libraries (if the profiler is enabled) and links to the system SQLite library whenever SYSTEM_SQLITE is enabled.
2017-03-26 10:10:15 +00:00
target_link_libraries(fgtestlib ${GooglePerfTools_LIBRARIES})
endif()
Test helper CMake macro. 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.
2017-03-26 11:15:29 +00:00
target_link_libraries(fgtestlib SimGearCore ${PLATFORM_LIBS} ${SQLITE3_LIBRARY})
Partial testing framework. 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.
2017-03-21 20:43:42 +00:00
add_executable(fgtest fgTestDriver.cxx)
target_link_libraries(fgtest fgtestlib)
Test helper CMake macro. 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.
2017-03-26 11:15:29 +00:00
macro(flightgear_test name sources)
add_executable(${name} ${sources})
Unit-test for initPosition. Only basic, but can be expanded incrementally now
2017-03-27 14:37:54 +00:00
target_include_directories(${name} PRIVATE ${CMAKE_SOURCE_DIR}/tests)
Test helper CMake macro. 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.
2017-03-26 11:15:29 +00:00
target_link_libraries(${name} fgtestlib)
add_test(${name} ${EXECUTABLE_OUTPUT_PATH}/${name})
endmacro()
Partial testing framework. 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.
2017-03-21 20:43:42 +00:00
Test helper CMake macro. 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.
2017-03-26 11:15:29 +00:00
flightgear_test(test_navs test_navaids2.cxx)
Fixed LaRCSim matrix computation routines. There was a couple of typos in the routine. This code will be used by the AI wake feature. Also added a test for the matrix code to make sure they will be no regression.
2017-06-05 15:18:52 +00:00
Added the core of the AI wake computations with its tests. At the moment, this is dead code: only the tests are compiled. FG is still compiled without this code. A new directory is created that contains all the numerical computations made to estimate the wake induced by AI aircrafts. This is based on the venerable Vortex Lattice Method (VLM) which was all the rage in the 60's Computational Fluid Dynamics (CFD). Even though quite old, the method is relevant to compute aircrafts wake in real time since 3D Navier-Stokes (NS3D) is out of reach for real time computations even with modern multicore personal computers and their GPUs.
2017-06-10 16:27:19 +00:00
add_executable(testAeroElement testAeroElement.cxx ${CMAKE_SOURCE_DIR}/src/FDM/AIWake/AeroElement.cxx)
target_link_libraries(testAeroElement SimGearCore)
add_test(testAeroElement ${EXECUTABLE_OUTPUT_PATH}/testAeroElement)
add_executable(testAeroMesh testAeroMesh.cxx
${CMAKE_SOURCE_DIR}/src/FDM/AIWake/AeroElement.cxx
${CMAKE_SOURCE_DIR}/src/FDM/AIWake/AircraftMesh.cxx
${CMAKE_SOURCE_DIR}/src/FDM/AIWake/WakeMesh.cxx
${CMAKE_SOURCE_DIR}/src/FDM/AIWake/AIWakeGroup.cxx
${CMAKE_SOURCE_DIR}/src/FDM/LaRCsim/ls_matrix.c
)
set_target_properties (testAeroMesh PROPERTIES COMPILE_DEFINITIONS "FG_TESTLIB")
target_include_directories(testAeroMesh PRIVATE ${CMAKE_SOURCE_DIR}/tests
${CMAKE_SOURCE_DIR}/src/FDM/JSBSim)
target_link_libraries(testAeroMesh SimGearCore JSBSim)
add_test(testAeroMesh ${EXECUTABLE_OUTPUT_PATH}/testAeroMesh)
Copy permalink