Управление опциями сборки (тестами и т. Д.) Во включенных библиотеках в современном стиле CMake - PullRequest
0 голосов
/ 01 октября 2018

Как лучше всего заменить глобальные переменные и вместо этого перейти к использованию целевых свойств для управления такими вещами, как создание тестов во включаемых библиотеках из файла CMakeLists.txt основных приложений?

Фон

У нас есть приложение C ++, A, которое, среди прочего, использует собственные библиотеки: lib B и lib C, которые включены как подмодули git в репозиторий A: s.Все репозитории (a, B и C) имеют общую внутреннюю структуру общей структуры, причем все они используют Gtest в качестве основы для модульного тестирования.Это приводит ко всем проектам, имеющим цель "unit_tests", а также цель "gtest".

Как следствие, при включении lib B и lib C в A: s CMakeLists.txt с использованием add_subfolder () возникаетконфликт, так как CMake требует, чтобы имена целей были уникальными, и в этих 3 репозиториях есть в общей сложности 3 цели "unit_tests".Есть и другие тестовые объекты, но они пока уникальны.Переименование тестовых целей в b_unit_tests и a_unit_test вылечило бы это, но это не правильно, и нам также нужно было бы переименовать цели gtest в a_gtest, b_gtest ...

В настоящее время мы решили это с помощью глобальных переменных CMake.B_BUILD_TESTS, C_BUILD_TESTS, которые установлены в false в A: s CMakeLists.txt и управляют включением теста в файлах B и Cs CMakeLists.txt с помощью add_submodule (unit_tests).Это не было реальной проблемой, поскольку мы не хотим создавать и запускать модульные тесты для lib B и C при сборке приложения A. Это было бы в основном пустой тратой времени.

Наблюдая за тем, как Дэниел Пфайферс ccpnow говорит и читает другие сообщения в блоге об использовании CMake декларативным способом, я начал переписывать нашу систему CMake с учетом современных практик CMake.Так что теперь использование установки глобального флага для каждой включенной библиотеки выглядит как анти-шаблон, который я хотел бы избежать.В идеале я считаю, что тесты лучше всего контролировать, устанавливая свойство для включенных целей.Нечто похожее на приведенное ниже.

add_subdirectory(B)
set_target_properties(B PROPERTIES BUILD_TESTS false)
target_link_libraries(A PRIVATE B)

В идеале это будет включать в себя цели тестирования bs, только сделайте так, чтобы они не зависели от основной цели b: s.Но это кажется очень трудным без переименования всех целей bs с префиксом b_.Технически b_unit_tests по-прежнему является целью, отличной от b, хотя из контекста A вы могли бы подумать, что она является частью цели B.

К сожалению, я не могу заставить работать вышеизложенное, как это уже похоже на CMake.имеет набор предопределенных свойств для целей, и добавление новых не поддерживается полностью.Существуют define_property и set_property, но из того, что я вижу, вы не можете использовать их для определения свойств целей.

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

Кажется, что для современного CMake библиотеки должны экспортировать свои пути и источники, и в процессе экспорта вы можете добавить пространство имен.Хотя я не совсем понимаю, должно ли это также относиться к библиотекам, которые включены как подмодули и собраны вместе с приложением?По этому маршруту я должен идти с библиотеками А и

1 Ответ

0 голосов
/ 01 октября 2018

Почему бы просто не переименовать тестовые объекты, чтобы они не конфликтовали друг с другом?Вы также можете управлять ими с помощью одной переменной BUILD_TESTS и установить ее по умолчанию ON или OFF в зависимости от того, как создается библиотека - как отдельный проект или как часть другого.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...