Как настроить CMake на установку пакетов?

Question

[Eugene Usachev]

C++ почти не знаю, но в ВУЗе дали практику, которую надо бы решить по-взрослому, то есть со сторонними библиотеками, пакетным менеджером, кросс-платформенностью и так далее. Конечно, я могу в README попросить установить все зависимости, но это выглядит костыльно. Хотелось бы, чтобы CMake сам установил все недостающие зависимости, а, может, даже пакетный менеджер.

Какой пакетный менеджер лучше взять? Как подключить его к CMake? Можно ли устанавливать его через CMake или лучше попросить об этом в README? Или "взрослое" решение пишется без пакетного менеджера?

Comments

[Василий Дёмин]

Я не плюсовик, конечно, но через CMake обычно никто ничего не ставит. Обычно как раз пишут, мол, установи то-то и то-то, потом уже собирай. Мой опыт основывается только на сборке пакетов из исходников.

[Дмитрий]

https://cmake.org/cmake/help/latest/guide/using-de...

Answer 1

[res2001]

Самому заниматься установкой зависимостей есть смысл только для статически линкуемых библиотек. В этом случае самый простой вариант такие библиотеки оформить например как субмодуль git. Тогда при клонировании вашего репозитория скачаются исходники библиотеки. В cmake просто собираете ее как отдельный таргет и используете по назначению. Хорошо если библиотека уже поддерживает сборку через cmake - будет меньше возни. Если нет, то придется написать самому для нее CMakeLists.txt.

Для динамических библиотек стоит оставить удовлетворение зависимостей пользователю, потому что вариантов пакетных менеджеров много (вы хотите их все поддерживать?). В вашем CMakeLists.txt нужно только сделать тем или иным способом поиск установленного пакета и если его нет - выдачу ошибки и завершение сборки. Такие механизмы в cmake есть. Можно использовать выше приведенный find_package или например pkg_check_modules (который в свою очередь использует утилиту pkg-config).
Почти все более-менее серьезные приложения не пытаются установить самостоятельно свои зависимости при сборке. Можете проверить. Например: https://github.com/nginx/nginx?tab=readme-ov-file#...

Вы можете дополнительно к сборке приложения добавить и создание пакета для пакетного менеджера (или для нескольких пакетных менеджеров). Вот тут то вы и укажите необходимые приложению зависимости (в разных дистрибутивах линукс пакеты с зависимостями могут называться по разному). И тогда, когда пользователь будет устанавливать ваш пакет через пакетный менеджер все зависимости установятся автоматически.
В cmake есть механизм для создания пакетов для разных пакетных менеджеров: https://cmake.org/cmake/help/book/mastering-cmake/...

Comments

[Eugene Usachev]

res2001, куда следует устанавливать статически линкуемые библиотеки (в какую папку проекта)? У Nginx я не нашёл папки с зависимостями (хотя мог плохо искать), у Tarantool есть папка third-party, у Aerospike что-то странное (есть папка modules, но по мимо неё существует pkg с пустыми папками).

Как их линковать мне тоже ещё не известно, но я думаю, что смогу это нагуглить, но, если Вам несложно, не могли бы вы задать вектор направления поиска?

[res2001]

Eugene Usachev,

куда следует устанавливать статически линкуемые библиотеки

Это не важно. Обычно заводят подпапку с произвольным названием (я использую обычно deps) и туда складывают субмодули. Вы же потом эту папку должны будете использовать в своем cmakelists.txt.

Как их линковать мне тоже ещё не известно

По линковке библиотек тут регулярно вопросы задают, несколько раз давал довольно развернутые ответы.
Но у вас есть система сборки cmake - у нее свои методы для этого, которые все равно в итоге приводят к добавлению необходимых ключей в командную строку компилятора.

не могли бы вы задать вектор направления поиска?

Для cmake после добавления таргета библиотеки обычными средствами add_library, просто добавляете его в зависимость к своему основному проекту:

...
add_library(third_party_libs ...)
...
add_executable(myprog ...)
target_link_libraries(myprog third_party_libs)

Если библиотека сама поддерживает сборку с помощью cmake, то проще всего собрать ее штатным способом, указав ее каталог в add_subdirectory(). В ходе сборки библиотека создаст свой таргет, его и будете использовать в своем проекте.
Если же библиотека не поддерживает сборку cmakeом, то придется проанализировать как она собирается, где лежат файлы исходного кода, где заголовки и сделать свою цель с помощью add_library. В этом случае нужно выделить интерфейсные заголовочные файлы (которые вы будете подключать в своем приложении) и отдельно указать их с опцией PUBLIC (или INTERFACE) в add_library.

Answer 2

[Станислав Макаров]

Какой пакетный менеджер лучше взять?

Conan или vcpkg, чё тут думать. Рекомендую Conan, но vcpkg тоже уже созревшее решение, сейчас они оба захватывают рынок.

Или "взрослое" решение пишется без пакетного менеджера?

А вы пилите библиотеку или законченное приложение? Опишите подробнее что у вас за программное средство. Требования сильно разные. Например:

• если это C++ библиотека - то я бы выбрал один из пакетных менеджеров и подготовил бы библиотеку для работы с ним. Например в случае Conan это значит написать conan-рецепт (который conanfile.py), который и будет "точкой входа" в вашу библиотеку: с помощью рецепта Conan узнаёт, как собирать библиотеку, какие у неё зависимости, как упаковывать в бинарный пакет, какие архитектуры и ОС поддерживаются и ещё кучу полезной информации, которую без ПМ обычно описывают ручками в README
  
• если это сетевой-сервис, например HTTP-бэкенд для чего-либо - ну тут стандартом индустрии является Docker/OCI-образ. Собираете образ под нужные комбинации архитектуры и ОС (см. multiplatform builds), заливаете в registry, и любой желающий запустит контейнер из вашего образа в своей инфраструктуре, или использует ваш образ как базовый для сборки своего
  
• если это десктопное приложение, неважно GUI или CLI - ну тогда обычно ожидается инсталляционный пакет под поддерживаемую ОС. Для Линуха это deb/rpm/flatpak/snap, для Венды - msix или exe, для Мака - dmg. Далее либо выкладываете для скачивания где-то на сайте, либо публикуетесь в магазинах типа Microsoft Store или Snapcraft
  

Опишите точнее ваш случай, я лучше посоветую что вам взять.

Comments

[Eugene Usachev]

Станислав Макаров, мне нужно написать два приложения: клиент с GUI, который по gRPC общается с сервером, и сам сервер. Я не знаю, на какой ОС будет собираться моё приложение. Мне сказали, что на него посмотрят, потом я пройдусь по всем компьютерам в компании и поставлю его. Оба проекта имеют общие зависимости, как минимум gRPC и сгенерированные proto файлы.

Вопросов у меня достаточно много, например, как создать общие зависимости для двух проектов, как эти проекты собирать под любую ОС? Но для начала, хочу собрать хотя бы сервер.

Я задал этот вопрос, чтобы прояснить ситуацию, так как разные ссылки в Гугле дают разные ответы, но на форуме ответы тоже разделились. Выше мне посоветовали скачать библиотеки без менеджера, Вы советуете его использовать.

[Станислав Макаров]

@Eugene-Usachev

Я не знаю, на какой ОС будет собираться моё приложение.

Желательно узнать это как можно раньше, т.к. даже если вы будете использовать кроссплатформенные библиотеки, конечную дистрибуцию поддерживать придётся под конкретные ОС. Лучше сразу узнать или договориться, под что нужно собирать клиент и сервер.

Оба проекта имеют общие зависимости, как минимум gRPC и сгенерированные proto файлы.

Тут бы я не спешил с выводами. Да, можно строить зависимости так, что proto-файлы у вас в каком-то отдельно пакете, от которого зависит и клиент и сервер, но вы вполне можете сделать так, что результатом сборки сервера будут помимо прочего ещё и proto-файлы, упакованные тем или иным образом. Это будет похоже на уже стандартный подход для HTTP-сервисов, когда для сервиса пишется руками или генерируется по коду OpenAPI-спецификация, и при релизе сервиса она тоже выкатывается куда-то в виде статического документа, доступного по HTTP, или в виде пакета. В этом есть логика: ведь сервис определяет, какая именно сейчас у него API-ха реализована, тем более если это не какая-то стандартная открытая спецификация (ну типа API S3), которую вы должны релизовать независимо от того нравится она вам или нет, а именно ваша спека gRPC-сервисов. Логично, что при выкатке новой версии сервиса будет выкатываться и новая спека в виде proto-файлов, которую можно подтянуть в клиенты. Заодно кстати и semver пригодится, про который вы спрашивали недавно.

Но для начала, хочу собрать хотя бы сервер.

Ну тогда рекомендую выбрать Linux, и сосредоточиться на сборке Docker-образа на базе какой-нибудь убунты. На Винде тоже есть нативный докер сейчас, и тоже принято паковать сервисы в виде образов контейнеров, но там свои заморочкки, можно будет добавить это позже, если вдруг понадобится. Вероятнее всего на сервере будет Линукс.

Я задал этот вопрос, чтобы прояснить ситуацию, так как разные ссылки в Гугле дают разные ответы, но на форуме ответы тоже разделились.

Ну это C++ коммьюнити, вот так тут заведено. C++ везде разный, инфраструктура и сборка ОЧЕНЬ разные в разных сферах и платформах. Игроделы, которые пилят под Винду, Мак и какую-нибудь Плойку делают по своему, Яндекс пилит свой бэк по-своему, везде разные ОС, разные библиотеки и разные системы сборки. CMake сейчас стал более-менее стандартом, но не то чтобы ему нет конкуренции, взять тот же Meson.
В отличие от JS, Go или Rust в C++ более-менее одинаковый только сам язык, всё остальное различается.

Выше мне посоветовали скачать библиотеки без менеджера, Вы советуете его использовать.

Люди достаточно инертны (это же C++), плюс что Conan что vcpkg это довольно сложные инструменты, это вам не NPM где херак-херак и зависимости поставились. С ними разбираться надо. С другой стороны, если вы не будете упаковывать библиотеку, а только два приложения, тогда вам будет значительно проще - Conan сильно проще использовать, если вам нужно только зависимости выкачать и конечное приложение собрать.

[Станислав Макаров]

@Eugene-Usachev
В общем у вас вопросы из разряда "как собрать и задеплоить приложение на C++?", в крупных проектах это считается за отдельную специализацию, называется build-инженер. Следовательно, в рамках ответа на тостере я вас полностью научить этому не смогу, но могу предложить конкретные направления, куда вы можете углубляться, если уж решили "делать по взрослому".

Answer 3

[Freeman]

Решил дать дополняющий ответ и оформить его в виде ответа, а не комментария.

Или "взрослое" решение пишется без пакетного менеджера?

С точки зрения ведения проектов у пользователя вашего кода должно быть целостное лицо:

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

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

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

Мораль в том, что с точки зрения ведения проектов тоже надо уметь смотреть, не только кодить.