Какие пыльные углы новичок в CMake захочет узнать?

Я сделал много проектов и множество различных систем сборки и инструментов CI. Совсем недавно я столкнулся с непростой задачей: добавить к среде на основе autotools для приложения С++ с разумным размером. Хотя мне нравится простота использования для конечного пользователя, я не очень люблю общаться с m4 и всеми инструментами auto * со стороны разработчика.

В свободное время я работаю над достаточно крупным проектом, и решил, что я хочу взять CMake для тестового диска. Поскольку я только начинаю, я, очевидно, планирую копать в документах /FAQ/wikis/etc. и учиться, делая. Кстати, я заработал деньги за книгу "Освоение CMake", но комментариев, которые я нашел на Amazon, было достаточно, чтобы заставить меня решить, что это, вероятно, не стоит денег. Все, что было сказано, во что-то новое, часто бывает "gotchas", что новичок часто спотыкается о том, что старые профессионалы уже давно научились избегать. Мне интересно, что они основаны на опыте людей с CMake, и я надеюсь немного сократить мои учебные проблемы, спросив здесь.

Изменить. Я должен указать, что я планирую использовать Linux в первую очередь и другие варианты UN * X. Windows не очень беспокоит мой POV. Это большое приложение на стороне сервера, с интерфейсом Web и CLI для операторов, северный интерфейс REST для автоматизации/интеграции с инструментами OSS и южный интерфейс SOAP для CPE. Мне понадобится много сторонних библиотек и приложений, чтобы заставить все это работать, если я не буду использовать следующие 10 лет, чтобы собрать все это вручную.:)

Ответы

Ответ 1

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

  • Всегда стремиться к сбоям вне источника: Очевидный: для проекта, предназначенного для встроенных источников, может быть сложно создать встроенный источник. Итак, если вы можете с самого начала его проектировать, ориентируйтесь на сборку вне источника.

  • Синтаксис: синтаксис может быть странным с множеством странных причуд, хотя это улучшается с версий 2.6 и 2.8.

  • Кэширование переменных. CMake отслеживает кеш переменных и настроек, и иногда это может быть проблемой при восстановлении чего-то. Попытайтесь удалить CMakeCache.txt(или очистить исходный каталог-источник) и перестроить. Это также упоминается DarenW.

  • Поиск и настройка сторонних библиотек: если у вас большой проект в зависимости от нескольких библиотек (ваш собственный или сторонний), это, вероятно, будет самым неприятным.

    • Я серьезно рекомендую погрузиться в команду find_package. Он очень мощный, но полностью зависит от качества файлов FindXXX.cmake. Особенно, если вы работаете на нескольких платформах (в основном Windows и Mac), эти файлы могут потребовать некоторой настройки или вам может понадобиться написать свой собственный.

    • Проблемы с связыванием библиотек, такие как отладка "undefined ссылок" или несоответствий между debug | release или static | shared, могут быть сложными для отладки. Особенно с сторонними библиотеками эти проблемы могут быть вызваны неправильными сторонними файлами FindXXX.cmake...

Ответ 2

Одна вещь, которая уделила мне некоторое время, чтобы понять: если что-то идет с haywire с сборкой, потому что я изменил параметр компилятора, добавил/удалил .c файл, имел путаницу с версиями библиотеки поддержки и т.д. - это лучше удалить дерево сборки и запустить cmake с нуля. В противном случае, несмотря на то, что cmake и make, похоже, выполняют свою работу, результирующий исполняемый файл сбой.

Может быть, мы "не делаем это правильно", но это становится общей проблемой со многими инструментами, языками, фреймворками и т.д. Невозможно, чтобы каждый был экспертом во всем программном обеспечении, от которого они зависят, и "не делать это правильно" - это единственный способ сделать многое даже среди профессионалов. CMake довольно умен в отношении многих вещей, но не все. Нукирование дерева сборки остается широко используемой техникой в ​​нашем проекте.