Можно ли не собирать тесты в cmake в релизе?

google://enable_testing

</thread>

А какой смысл не собирать тесты в релизе? Их там как и надо собирать. А запускаются они вообще-то по make test

Конечно.

Добавляешь пустой таргет tests (название по своему усмотрению). На таргеты тестов навешиваешь свойство EXCLUDE_FROM_ALL. Таргет tests делаешь зависимым от всех таргетов тестов (add_dependencies).

В этом случаи бинарники тестов по умолчанию не собираются. Для их сборки явно указываешь нужную цель: cmake –build . –target tests (или собрать все: –target all).

Для запуска тестов у CMake есть утилитка ctect. Тесты для этого регистрируются командой add_test.

И да, в релизной сборке тесты все же нужно собирать/запускать.

На таргеты тестов навешиваешь свойство EXCLUDE_FROM_ALL

add_custom_command тогда уж. Есть же BUILD_TESTING

Не-а, не так. Не нужна тут add_custom_command.

add_executable(test EXCLUDE_FROM_ALL test.cpp)

if (CMAKE_CROSSCOMPILE)
  set(BUILD_TESTING OFF CACHE BOOL "")
endif ()
include(CTest)
add_test(...)

Дальше пользователь сам вырубит, если не нужно будет. Ну или по CMAKE_BUILD_TYPE смотри. Только с multiconfig генераторами(или как их там) не прокатит

Конечно не нужна, как и EXCLUDE_FROM_ALL и прописывание зависимостей вручную

Ну можно еще проще сделать, вынести сборку тестов в отдельную директорию со своим CMakeLists.txt и в зависимости от опции установленной пользователем подключать или не подключать ее.

Да

Но мне этот способ не подошел, т.к. Visual Studio сносит всю директорию сборки при переконфигурации проекта.

В том же cmake-е сделай. Я пример не совсем полный дал:

-add_test(...)
+if (BUILD_TESTING)
+  add_executable(...)
+  add_test(...)
+endif ()

Да понял я, понял. Но это не отменяет того, что опцию BUILD_TESTING нужно переключать. А это не всегда удобно. Иногда проще явно скомандовать «собрать тесты», без изменения переменных.

Поинт в том, что BUILD_TESTING - стандартная опция, и собирающему не придётся ковыряться в скриптах сборки, чтобы узнать каким образом управлять сборкой тестов. Для внутреннего продукта не так важно, но если сырцы выпускаются в лапы неискушённых пользователей/разработчиков, ничего кроме самого настоящего батхерта это им не доставит

Дописать в README одну строчку с командой cmake –build . –target tests не вариант?)

А как не особо искушенный пользователь я предпочитаю смотреть конфиги Travis/AppVeyor. По ним сразу ясно как собирать и запускать тесты.

Вкусовщина все это.

Тесты должны запускаться всегда: хоть в дебаге, хоть в релизе. Простейший пример - добавил ты дебажный вывод в модуль, оперирующий потоками выполнения и приехали: поведение его у тебя будет меняться в зависимости от того сработал вывод или нет.

А вот когда пишешь сценарий для сборки пакета, тесты можно там и отключить.

А какой смысл не собирать тесты в релизе?

Не тратить время на сборку тестов.

Их там как и надо собирать.

Но зачем? Разве запуска тестов в дебаге не достаточно?

И да, в релизной сборке тесты все же нужно собирать/запускать.

С какой целью?

Твои пользователи дебаг версию будут использовать? Если да - тестируй только в дебаге.

Точнее даже так - это дебаговские сборки можно в основном не делать, а собирать по умолчанию в RelWithDebInfo.

По хорошему, тестировать надо то, что ты отдаёшь пользователю. Ты сейчас пытаешься улучшить то, что не требует улучшений. Лучше на написание нормальной установки и сборки пакетов время потрать