Думаю никого не нужно вводить в курс дела - в С++ всегда было сложно с подключением зависимостей. Было. Первым из пучины баш и питон скриптов естественным отбором появился и повсеместно распространился cmake - на этом этапе хотя бы проекты без зависимостей стало можно собрать как-то одинаково (здесь я намеренно не упоминаю прочие инструменты того же толка, они просто гораздо менее популярны)

Важно понимать, что до момента когда cmake массово распространился ни о каких пакетных менеджерах для С++ даже не имело смысла говорить - ведь не было пакетов. И только с появлением CMakeLists.txt в каждой библиотеке стало возможным хотя бы рассматривать проекты как пакеты, которые можно как-то распространять

И этим сразу же начали заниматься. Можно сказать, что этот процесс идёт прямо сейчас, но основные тенденции уже наметились. Подходы разные, я расскажу о нескольких самых популярных:

(почему не) Conan

Conan решил не делать революции и остался продвинутым питон скриптом. Идея простая - вы пишете "рецепт" на питоне для вашего пакета, потом складываете в какой-то центр рецептов, потом используете. Но есть нюансы:

1. нужно написать рецепт. А ведь вы уже писали "рецепт", CMakeLists.txt называется

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

3. совершенно неочевидно как же он должен быть написан - на примере множества людей и компаний выявлено, что написание conan рецепта это один из самых сложных навыков в программировании. Люди спокойно разбираются в шаблонах, в линуксе, в ужасной документации, но написать conan рецепт не могут

4. сочетание пунктов 2 и 3 делает возможным поддержание рецептов для разных библиотек возможным только для больших компаний, которым некуда девать человекочасы

5. нужен питон. Видимо какой-то стабильной версии

И самый большой нюанс в том, что у большинства библиотек никаких конан рецептов нет, писать их вы не хотите, а у одиночных разработчиков и маленьких команд зачастую нет сил/желания писать эти рецепты и проходить потом через процедуру ревью в conan-index-center и поддерживать этот рецепт потом в течение 40 лет (не забывайте, что уже есть conan2)

Основное применение конана сейчас это написать в комментариях к чему угодно "а почему не КоНАн?", эдакая заглушка для нормального решения проблемы зависимостей в С++

(почему точно не) vcpkg

Тут путь совсем странный и даже тупиковый. По сути в майкрософт решили сделать список одобренных ими библиотек - даже не знаю как в этот список попасть. Теоретически процесс похож на конан. Рецепт (порт) -> индекс -> использование. Но на практике оказывается, что даже версии библиотек это что-то невероятное для vcpkg, локальный индекс пакетов на уровне эксперимента, а ежемесячный отчёт об обновлениях всё больше похож на мем:

Давно уже ощущение, что не смотря на громадные возможности майксрософта - у них есть гитхаб, Windows, громадные деньги и влияние - проект просто загнулся и больше не развивается

CPM

CPM реализует простую и очевидную идею - CMakeLists.txt это уже и есть рецепт библиотеки. Преимущества:

1. Простота. CPM это всего лишь один файл на cmake . Если проблемы возникают, они обычно понятные, так как механизм работы прост и прозрачен

2. рецепты не нужно поддерживать специально, они просто есть, если CMakeLists.txt написан

3. Не нужен выделенный реестр пакетов, индексом может стать и github и gitlab и ваш локальный файл и в целом что угодно

4. Если автор библиотеки накосячил с "рецептом", всегда можно сделать патч прямо при добавлении зависимости

5. Теоретически CPM может переиспользовать Conan и vcpkg через свой интерфейс CPMAddPackage, тогда как в обратную сторону это не работает

Теперь соберём из этого всего удобные шаблоны проектов

Моей целью стало не сделать самый универсальный инструмент для всего, а просто организовать удобным образом создание новых проектов на С++.

Например: вы хотите написать бенчмарк. Но стоит вам только подумать, что для этого нужно будет настраивать проект, подключать зависимости из google benchmark.. Люди часто бросают идею именно на этом этапе.

Из этой проблемы выросли целые проекты по типу https://quick-bench.com/, он хотя бы как-то запускает ваш бенчмарк. И даже не спрашивайте как ТУДА добавить свои зависимости.

Поэтому первым шаблоном стал шаблон бенчмарка

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

git clone https://github.com/kelbon/template_benchmark
cd template_benchmark
cmake -Dproject_name=<your-project-name> -P setup.cmake

Обычно после запуска скрипта у С++ программистов на глазах слёзы счастья, когда они видят, что после билда можно просто нажать F5 в vscode и проект запустится, потому что launch.json уже сгенерирован за них, compile_comands.json переложен туда, откуда clangd сможет организовать подсветку кода, а google benchmark в зависимостях с правильными опциями, чтобы он не ломал сборку (как он любит)

Потом появились шаблоны библиотеки и приложения, а потом и просто в репозиторий со списком всех шаблонов

Так, для библиотеки сразу в комплекте идёт CI на гитхабе с санитайзерами на gcc и clang, кеш сборки (кроссплатформенный ccache), clang-format, автоматическое добавление тестов и конечно же deps.cmake для перечисления зависимостей.

Для приложения ещё и добавляется сразу зависимость и файлы для описания CLI интерфейса на компиляции, в удобном и понятном виде

Радует, что мир С++ настолько очистился, что стало возможным создание таких проектов. В будущем планируется добавить также шаблон HTTP сервиса (там почти всё готово), но и нынешний набор уже очень помогает при создании новых проектов, что может очень сильно помочь в обучении языку, поэтому решил поделиться шаблонами проектов