Open-Harbor/osrm-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity
fae1c737a3
osrm-backend/unit_tests/CMakeLists.txt

83 lines
2.7 KiB
CMake
Raw Normal View History

Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
file(GLOB EngineTestsSources
engine_tests.cpp
engine/*.cpp)
file(GLOB ExtractorTestsSources
extractor_tests.cpp
extractor/*.cpp)
always emit a small component view Unit Tests for Reodering by Predicate
2017-02-01 09:50:06 -05:00
file(GLOB PartitionTestsSources
partition_tests.cpp
partition/*.cpp)
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
file(GLOB LibraryTestsSources
library_tests.cpp
library/*.cpp)
file(GLOB ServerTestsSources
server_tests.cpp
server/*.cpp)
file(GLOB UtilTestsSources
util_tests.cpp
util/*.cpp)
add_executable(engine-tests
EXCLUDE_FROM_ALL
${EngineTestsSources}
$<TARGET_OBJECTS:ENGINE> $<TARGET_OBJECTS:STORAGE> $<TARGET_OBJECTS:UTIL>)
add_executable(extractor-tests
EXCLUDE_FROM_ALL
${ExtractorTestsSources}
$<TARGET_OBJECTS:EXTRACTOR> $<TARGET_OBJECTS:UTIL>)
always emit a small component view Unit Tests for Reodering by Predicate
2017-02-01 09:50:06 -05:00
add_executable(partition-tests
EXCLUDE_FROM_ALL
${PartitionTestsSources}
$<TARGET_OBJECTS:PARTITIONER> $<TARGET_OBJECTS:UTIL>)
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
add_executable(library-tests
EXCLUDE_FROM_ALL
${LibraryTestsSources})
add_executable(server-tests
EXCLUDE_FROM_ALL
${ServerTestsSources}
$<TARGET_OBJECTS:UTIL> $<TARGET_OBJECTS:SERVER>)
add_executable(util-tests
EXCLUDE_FROM_ALL
${UtilTestsSources}
$<TARGET_OBJECTS:UTIL>)
disable BOOST_TEST_DYN_LINK if Boost_USE_STATIC_LIBS
2016-05-20 00:03:37 -04:00
if(NOT WIN32 AND NOT Boost_USE_STATIC_LIBS)
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
add_definitions(-DBOOST_TEST_DYN_LINK)
endif()
Hardcode path to test data dir for library-tests This was needed because we now need multiple datasets for testing. CMake will automatically prepare these over the makefile in test/data.
2017-03-05 17:53:41 -05:00
set(TEST_DATA_DIR "${CMAKE_SOURCE_DIR}/test/data")
add_dependencies(library-tests osrm-extract osrm-contract osrm-partition)
Disable building test data on windows
2017-03-07 08:47:32 -05:00
# We can't run this Makefile on windows
if (NOT WIN32)
add_custom_command(TARGET library-tests POST_BUILD COMMAND make -C ${TEST_DATA_DIR})
endif()
Hardcode path to test data dir for library-tests This was needed because we now need multiple datasets for testing. CMake will automatically prepare these over the makefile in test/data.
2017-03-05 17:53:41 -05:00
Make absolute fixtures path
2016-12-04 06:55:11 -05:00
target_compile_definitions(extractor-tests PRIVATE COMPILE_DEFINITIONS OSRM_FIXTURES_DIR="${CMAKE_SOURCE_DIR}/unit_tests/fixtures")
Hardcode path to test data dir for library-tests This was needed because we now need multiple datasets for testing. CMake will automatically prepare these over the makefile in test/data.
2017-03-05 17:53:41 -05:00
target_compile_definitions(library-tests PRIVATE COMPILE_DEFINITIONS OSRM_TEST_DATA_DIR="${TEST_DATA_DIR}")
Make absolute fixtures path
2016-12-04 06:55:11 -05:00
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
target_include_directories(engine-tests PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_include_directories(library-tests PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_include_directories(util-tests PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
add unit tests for the different components of the parttion tool
2017-02-02 09:53:42 -05:00
target_include_directories(partition-tests PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
cmake fixes: - Builds up ENGINE_LIBRARY_LISTING correctly to pass to pkg-config - Previous behavior had major flaw and would result in paths in libosrm.pc like: "-L-L" when the data was "-L/path -lfoo" or just "-lpthread" with no -L/path. It only worked correctly for static libraries - Refactors to call find_package for boost in one place (helps prepare for upcoming mason PR)
2016-10-20 12:59:37 -04:00
target_link_libraries(engine-tests ${ENGINE_LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
target_link_libraries(extractor-tests ${EXTRACTOR_LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
always emit a small component view Unit Tests for Reodering by Predicate
2017-02-01 09:50:06 -05:00
target_link_libraries(partition-tests ${PARTITIONER_LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
Changes Single Coordinate Geoms from Point to LineString, closes #3425.
2016-12-08 07:20:23 -05:00
target_link_libraries(library-tests osrm ${ENGINE_LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
minor build fixes - Travis: Upgrade clang from 3.8.0 to 3.8.1 (provides smaller package for faster downloading) - Travis: Makes BUILD_COMPONENTS an option - Followup after #3130 (Boost_LIBRARIES variable no longer exists)
2016-10-27 16:39:33 -04:00
target_link_libraries(server-tests osrm ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
cmake fixes: - Builds up ENGINE_LIBRARY_LISTING correctly to pass to pkg-config - Previous behavior had major flaw and would result in paths in libosrm.pc like: "-L-L" when the data was "-L/path -lfoo" or just "-lpthread" with no -L/path. It only worked correctly for static libraries - Refactors to call find_package for boost in one place (helps prepare for upcoming mason PR)
2016-10-20 12:59:37 -04:00
target_link_libraries(util-tests ${UTIL_LIBRARIES} ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
Start modularizing the CMake buildsystem The main reason for modularizing the unit tests was to split off libboost_unit_test_framework from the osrm toolchain binaries. Now only the unit test binaries link against it, unblocking binary distribution without unit test library dependencies. I started this on v4 a couple of weeks ago and hit a -llua5 issue on Travis. By now v5 diverged quite a bit (especially in the code that I have to stare at for debugging the issues). https://github.com/Project-OSRM/osrm-backend/pull/2073 Let's bring this to v5+ only. This is blocking: - https://github.com/Project-OSRM/osrm-backend/issues/2065 - https://github.com/Project-OSRM/osrm-backend/issues/2197#issuecomment-204864938
2016-04-06 06:44:46 -04:00
add_custom_target(tests
Hardcode path to test data dir for library-tests This was needed because we now need multiple datasets for testing. CMake will automatically prepare these over the makefile in test/data.
2017-03-05 17:53:41 -05:00
DEPENDS engine-tests extractor-tests partition-tests library-tests server-tests util-tests)
Reference in New Issue Copy Permalink