CMake find_package не обрабатывает мультиконфигурации

Question

Мы используем Jenkins 2.60.2 и CMake 3.9.1 для автоматизации нашей системы сборки. Все это хорошо работает для нескольких версий инструментов сборки, архитектур и целей отладки / выпуска (если ВСЕ конфигурации были созданы и установлены, то и Debug AND Release).

Конфигурация только для отладки, использующая find_package (), обычно игнорирует CMAKE_BUILD_TYPE при обнаружении. Внутри скрипты ищут файлы и библиотеки и сохраняют местоположения в переменных. В конце скрипта переменные сканируются на наличие строк _NOTFOUND, что является результатом того, что файл или библиотека не найдены во всех ссылочных путях / подсказках. Таким образом, по сути, find_package () завершится ошибкой, если не удалось найти Release Release, и пометит весь пакет как не установленный должным образом, даже если сборка строго заинтересована в цели Debug.

Обычно в файлах XXXConfig.cmake используется вызов find_package_handle_standard_args (.. PATH_TO_LIB), который сканирует строки _NOTFOUND в переменных пути к библиотекам. Эти переменные обычно устанавливаются в _NOTFOUND более ранними вызовами find_library (имя_библиотеки PATH_TO_LIB..). Для получения дополнительной информации я обращаюсь к документации CMake.

Пользователь действительно может пометить библиотеки отладки с помощью "debug" и выпустить libs с "optimized", но это, похоже, не помогает во время обнаружения lib и используется только во время компоновки.

Кто-нибудь знает, как правильно с этим справиться?

С уважением

Answer 1

Это один из прискорбных недостатков классического использования find_package,

Обратите внимание, что find_package также допускает другой режим работы, основанный на пакетах файлов конфигурации, который хорошо подходит для решения этой конкретной проблемы, но потребует некоторых изменений в вашей системе сборки. Вам понадобятся скрипты конфигурации для всех ваших библиотек (CMake может сгенерировать их для вас, если сами библиотеки также собраны CMake; если нет, это может быть немного хлопотно), и зависимые цели будут ссылаться на эти библиотеки через импортированные цели вместо переменных (что обычно облегчает задачу зависимым целям). Я настоятельно рекомендую вам принять это как долгосрочное решение.

Если по какой-либо причине вы не можете сделать это, вам придется изменить свои скрипты поиска. Обычный метод - искать двоичные файлы отладки и выпуска отдельно, а затем объединять библиотеки поиска из этих вызовов в одну переменную (вместе с debug а также optimized спецификаторы), а затем иметь эту переменную в качестве аргумента find_package_handle_standard_args, Таким образом, до тех пор, пока будет найден один из двух, ваш скрипт поиска будет счастлив, хотя в итоге вы не сможете собрать все возможные конфигурации. Кроме того, вы также можете пропустить звонок find_package_handle_standard_args в целом и вручную реализовать собственную логику для определения, была ли найдена библиотека. Как вы можете видеть из справочной страницы по этой функции, она в основном выполняет типичные функции и может быть легко заменена более гибкой, написанной от руки реализацией, если это необходимо.