Conan, пакетные менеджеры в С++

Сразу хочу сказать - я с cargo не работал.

Ну и что мне объяснять?

В карго я бахаю somelib=«*» и всё работает. На всех ОС. Я могу также сделать в conan?

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

Да, можешь.

Давайте пример.

По моим наблюдениям, наиболее вероятные претенденты на звание «Пакетный менеджер для C++ по умолчанию сейчас»: Conan и Vcpkg. В том же vcpkg сейчас активно пилят поддержку предкомпилированных библиотек и кроссплатформенность. Также у меня есть подозрения, что MS вливают неплохие деньги в развитие vcpkg.

Conan продался Artifactory и теперь зарабытвает деньги как часть каких-то доходов от Bintray. Ну и пиар у Conan самый сильный.

Мне скинуть ссылку на проект, который тянет зависимости с помощью Conan или привести пример такого conanfile.txt, который подтягивает зависимости кроссплатформенно? не совсем понимаю.

conanfile.txt,

Расширение .txt необходимо?

а с каких пор vcpkg стал системным пакетным менеджером? :-)

Просто hello world или существующий проект на гитхабе.

Сайт у конана настолько убог, что без поллитра не разобраться.

Там на выбор есть conanfile.txt и conanfile.py. В conanfile.txt можешь просто описать зависимости и в какую билд-систему это дело встроить надо.

В conanfile.py можешь описать более сложные вещи (по расширению понятно, что описывать на Python), такие как опциональные зависимости под каждую платформу.

conanfile.txt,

Расширение .txt необходимо?

Там на выбор есть conanfile.txt и conanfile.py

Кхм. Я спрашиваю - после переименования conanfile.txt в conanfile будет ли conan работать так же, как при существовании conanfile.txt?

https://github.com/ZaMaZaN4iK/conan_project_example

а с каких пор vcpkg стал системным пакетным менеджером? :-)

С тех пор, что это пакетный менеджер для Windows и сделан Microsoft.

Ну так то он и под Linux уже работает. А то, что сделан Microsoft - какая разница?

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

Спасибо. Потыкаю.

В винде вообще всё принято с собой нести. :)

Текст — копипаста, содержащая рекламу. Эти проекты ты сам не используешь, а просто приходишь и кидаешь копипасту. Цель — выгода для конкретного проекта. Я считаю, что это спамерство.

Сборщик сисрута — нужно

Покажите сборщик сисрута с поддежкой Linux и Windows (включая MSVC). Пока ничего лучше сборки сисрута конаном я не придумал

То-есть после подобной правки проект естесственно нигде кроме конана собираться не будет

if (EXISTS ${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
...

Считай как хочешь :-) Лично я вижу выгоду для всего C++ коммьюнити в целом и для себя в частности. Чем больше библиотек я смогу поставить с помощью Conan, тем легче мне будет жить. И тоже самое я обьяснил саппорту GutHub, когда с меня спросили за спам. Они с моей ТЗ согласились.

И с этим нужно бороться, я считаю. Потому что это вообще никуда не годиться :-)

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

Оправдание достойное спамера.

Окей, пусть будет по-твоему.

С этой темой всё намного сложнее, согласен. Так как у каждого дистра свои правила распространения программ: на винде тянем всё с собой, на линуксах либо берём системные пакеты (а они могут отличаться от тех версий, что мы используем для сборки с помощью Conan), либо снова же тянуть всё с собой в каком-нибудь Flatpak/Appimage/Snap, в macOS я не знаю, как там сделано.

В Conan ЕМНИП был реквест о том, чтобы добавить опцию сборки с системными версиями зависимостей.

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

Ага, и в провайдерах и у хостеров(google://zentoo) её тоже не используют, да-да-да

Предполагать, что я не знаю, что такое Gentoo и как она используется - это какой-то запредельный дефицит ЧЮ.

Вопрос уровня если Makefile переименовать в mybuildscript будет ли make его подхватывать без дополнительных опций?

Ну извини. Без обид, но «В этом вашем Интернете уже и не понятно кто прикалывается, а кто реально дебил» (c)

Вопрос уровня если Makefile переименовать в mybuildscript будет ли make его подхватывать без дополнительных опций?

Возможно, я ошибаюсь, но в cmake просто невозможно указать другое имя для CMakeLists.txt; при этом файл для make может называться Makefile, makefile, GNUMakefile и еще как-то (для всяких малоизвестных make). Не вижу ничего странного в своем вопросе.

Это уже проблема сообщества. А то про гайдлайны знают 2.5 человека и из них пользуются ими 2%. А потом удивления - че ет у нас все такие разношёрстные либы - кто во что горазд.

А, ты об этом. Просто make может принять вообще любое имя для makefile(ключ -f ЕМНИП). А вот с cmake да похоже всё тухло...

Dscclamer: скажу только за Gentoo

А если нет в пакетном менеджере? А если нет нужной версии?

Простейший пакет пишется минут за 5 мин и кладется в локальный оверлей (просто каталог). Типовая задача.
Детальней здесь: https://wiki.gentoo.org/wiki/Basic_guide_to_write_Gentoo_Ebuilds . Притом в примере «The ebuild should look like this» (7 строк без комментариев и пробелов) предполагается скачать исходники, распаковать, выполнить ./configure, make, make install - это явно не указано, но, если там все стандартно, то portage сам знает что делать. Если добавить одну строчку с DEPEND, то оно ещё и притянет зависимости. Если добавить одну строчку с IUSE, то этого достаточно чтобы кастомизировать сборку при условии, что ./configure принимает аргумент --enable-XXX (стандартная практика). Естественно, можно кастомизировать любую стадию. Вот здесь более сложные примеры: https://devmanual.gentoo.org/quickstart/

А если патч нужно сверху наложить?

Тоже типовая задача: есть патчи, которые идут с пакетом, есть кастомные, твои собственные, которые менеджатся отдельно - просто положи в каталог, portage сделает всё за тебя.

Или сконфигурировать со специфическими параметрами?

USE-флаги именно это и делают. Детальней здесь: В чем преимущество USE-флагов перед опциями сборки? (комментарий)

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

Управление зависимостями есть почти в любом дистрибутиве, так что для распространения бинарников проблема не стоит. Я так понял, что здесь именно зависимости на этапе компиляции/линковки.

Вобщем, я для себя вывод сделал: для тех,у кого Gentoo, вопрос не стоит. Проблема только для тех, кто не на Gentoo, или кому нужно переносить сборки на не-Gentoo.

Только у Си/Си++ ничего сиандартного нет.

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

Мавен, к слову, даже не от хрюнакла, о какой стандартности речь вообще?

Нет. Потому что на них пишут много и экосистема меняется быстро.

Пишут на них много, но ничего важного.

Вся соль в том, что из-за множества факторов пакетный менеджер для C/C++ реально сложно сделать правильным - есть разные платформы, разные архитектуры, разные системы сборки (в том числе самодельные скрипты). Либы определённые можно взаимозаменять. При сборке можно их ещё конфигурять, включать/отключать компоненты и сильно менять поведение. Либа может банально не собраться по множеству причин.

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

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

Скажите это разработчикам C++ на Windows

Это их проблемы.

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

Попробуй порулить пакетами через pip в обход пакетного менеджера дистра, несложно на системе весь стек питоний сломать.

Кстати, да. А какие есть способы это делать стандартно, кросс-платформенно и с прицелом на клиента? Я про питон.

То-есть после подобной правки проект естесственно нигде кроме конана собираться не будет

if (EXISTS ${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)

Когда люди пишут Getting Started они должны показать тривиальный рабочий пример. Предположим у меня есть готовый проект, как пакетным менеджер мне его сконфигурирует, соберёт, показать как установить зависимости и т.п. Конан же нам говорит со старта: модифицируйте код проекта под меня любимого. Не под абстрактный тулчейн с сисрутом, не используя стандартные методы поиска зависимостей, а прибейте гвоздями какой-то доморощеный файл себе в проект. Простите, но это ни в какие ворота. Что в этом файле и зачем он, если в самом проекте на CMake уже есть ВСЁ готовое для его сборки в чужеродном окружении: этап конфигурации с экспортированием параметров, кросскомпиляция, работа с pkgconfig, с абстрактным тулчейном и т.д. Магия недопустима, должно даваться чёткое понимания каждого шага, что и зачем я делаю таким способом, как разделить задачи пакетного менеджера от задач сборки самого проекта.

Предположим, я в своём проекте решил использовать libcurl, который тоже на CMake, мне что, его нужно патчить, чтобы он заработал в Конане? А ведь тривиальный пример и хочет нам это сказать.

Попробуй порулить пакетами через pip в обход пакетного менеджера дистра, несложно на системе весь стек питоний сломать.

С правами рута всё несложно сломать. Но пойнт pip в том, что с его помощью можно собрать что-то локально у себя в хомяке.

Мавен, к слову, даже не от хрюнакла, о какой стандартности речь вообще?

О фактической.

Потому что на них пишут много и экосистема меняется быстро.

Пишут на них много, но ничего важного.

Важно или нет - это субъективное мнение. Пишут много, экосистема развивается быстро. Без пакетного менеджера там тупо не справиться.

Вся соль в том, что из-за множества факторов пакетный менеджер для C/C++ реально сложно сделать правильным

Да, Капитан. Отчасти поэтому его до сих пор и нет. Но хорошо бы, если бы он был.

Dscclamer: скажу только за Gentoo

С Генту дело и имел, но судя по ликбезу, его разработчики подошли к задаче управления пакетами с правильной стороны. Если бы только это работало за пределами Линукса и самого Генту в частности, ведь разработка под тот же Windows, это не мифическая задача и сбрасывать её со счетов это потеря пользователей, оставаясь быть маргинальной системой для тех кто в теме.

В принципе, как я уже сказал, тот же bitbake это пока единственная альтернатива, которую можно рассматривать серьёзно, по крайней мере из того, что я использовал в своей практике.

Вообще сама постановка задачи: пакетный менеджер для C++ звучит бредово. Это как такси отдельно для умных и красивых, а что если нужно посередине? При разработке программы сплошь и рядом возникает задача настройки окружения сборки, к примеру, забутстрапить тот же тулчейн перед его использованием. Или, скажем, для сборки моего проекта на C++ должен использоваться некий CMake 3.42, которого нет в системе, как мне Конан поможет его собрать до начала конфигурации моего проекта? Или в проекте может использоваться множество языков программирования, мне что под каждый ставить свой пакетный менеджер?

Тот же bitbake даёт ответы на все эти вопросы. А когда я слышу фразу «пакетный менеджер для C++», это воспринимается как «нож для нарезки помиродов». Собрались сделать салат из 10 ингридиентов? Воспользуйтесь набором ножей под каждый овощ в отдельности.

Вообще сама постановка задачи: пакетный менеджер для C++ звучит бредово.

Почему? Только без метафор.

Сборка приложений в общем случае подразумевает многоступенчатый процесс, пакетирование и конкретный язык программирования лишь малая его часть. Зависимости могут быть как на уровне хостовых утилит, так и целевых платформ и использовать они могут совершенно разные инструменты, далеко выходящие за С++. К примеру, какой-то зависимости понадобился python3.6, как его универсально собрать и поставить на произвольном сервере сборки, установить на него зависимость в твоём пакете, убедиться, что другой пакет, которому понадобился конфиликтующая версия python, его не увидит, указать для какого именно этапа сборки понадобился этот python, для конфигурации, компиляции, пакетирования или может для копирования его кусков на целевую платформу?

Или, предположим, я собираю свою программу для десктопного Линукса, Виндовза, Андроида и ещё некоей кустарной эмбедовщины. Естественно, я хочу однородную систему управления зависимостями, но вот в Андроиде используется Gradle, получается мне теперь нужно в разработке использовать несколько систем управления зависимостями? Для C++ — Conan, для Android/Java — Gradle, для Python — PIP, etc, и в документации указывать простыню из N шагов как нужно всё это собирать случайному прохожему. Таки когда речь заходит об управлениями зависимостями, она не должна быть прибита гвоздями к языку и легко расширяться при необходимости.

Так что _бредового_ в попытке решить эти задачи? Пока что ты только описываешь, сколь они сложны. Не все их нужно решать в универсальном инструменте, кстати.

но вот в Андроиде используется Gradle, получается мне теперь нужно в разработке использовать несколько систем управления зависимостями? Для C++ — Conan, для Android/Java — Gradle, для Python — PIP, etc

Да. И чем это хуже текущей ситуации, когда ты используешь Gradle для Java, pip для Python, и что-то самодельное - для Си++?

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

Почем, если оно упрощает задачу? Я могу сказать, что pip практически полезен. Почему идея сделать подобный инструмент для Си++ - бред?

PIP задумывался и разрабатывается как часть самого Python, концепция модулей в языке стандартизирована. Пласт задач, которые решаются на Python без привлечения сторонних инструментов достаточно большой.

C++ же совсем другая история. По сути это стандарт, причём довольно широкого толкования. Голый стандарт C++ в практическом плане абсолютно нежизнеспособен без его сужения и обростания множеством сторонних инструментов. К примеру, выбору определённой модели данных (LP), ABI, битности, архитектуры, компилятора, каждый со своим богатым уникальным набором опций и хаков, огромного количества существующих систем сборки, особенностей ОС и, непобоюсь этого слова, систем контроля версий. Говорить про некий пакетный менеджер для абстрактного C++ в вакууме это ни о чём без поддержки огромного стороннего набора инструментов, которым этот C++ должен сопровождаться.

Система управления зависимостями для C++ при этом мгновенно эскалируется до системы управления зависимостями между всеми этими инструментами. Даже некий элементарный cat мгновенно обрастает какой-нибудь man-страницей, файлами конфигураций, которые требуют своих собственных разнообразных зависимостей, чтобы их скомпилировать, опакетировать и установить в систему.

PIP задумывался и разрабатывается как часть самого Python

Нет. pip - позднее дополнение.

Голый стандарт C++ в практическом плане абсолютно нежизнеспособен без его сужения и обростания множеством сторонних инструментов. К примеру, выбору определённой модели данных (LP), ABI, битности, архитектуры, компилятора, каждый со своим богатым уникальным набором опций и хаков, огромного количества существующих систем сборки, особенностей ОС и, непобоюсь этого слова, систем контроля версий

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

Невозможного ничего нет, яркий пример тому тот же Bitbake, который является идейным продолжателем Portage. Смущает сама постановка задачи: пакетный менеджер C++. Или такой пакетный менеджер будет сам по себе нерабочим без ручной настройки окружения и привинчивания 100500 других пакетных менеджеров под разные ОС, языки, тулчейны и т.д. Или он мутирует в что-то большее, пытаясь перетянуть одеяло на себя.

Смущает сама постановка задачи: пакетный менеджер C++

Вас, наверное, так же смущают «пакетный менеджер для Ruby», «пакетный менеджер для Haskell», «пакетный менеджер для Rust», «пакетный менеджер для D», «пакетный менеджер для Go» и пр. вещи, которые делают разработку на вышеперечисленных языках гораздо более комфортной?

Знаете, так уж получилось, что я в обнимку с C++ уже больше 25 лет. Наелся за это время всякого. И обзавидовался всякому, что есть в более нормально развивающихся языках. И вот таким персонажам как вы, хочется сказать: вы бы держали свое мнение в той заднице, откуда его вытащили.

Про проблемы построения менеджера зависимостей (как и системы сборки) для C++ многие знают (не по наслышке) получше вас. Но это не отменяет того простого факта, что C++у нужен свой менеджер зависимостей. Кроссплатформенный, не прибитый гвоздями ни к какому конкретному Linux-у, ни к какой другой ОС. Вот просто нужен и все. Нужен давно и в последние годы это все более и более очевидно.

И если вам это не очевидно, если вы не хотите иметь такую штуку, то просто закройте рот и постойте в стороне. Пусть попробуют поработать те, кто настроены более оптимистично.

Я не Dendy, но отвечу:

вы бы держали свое мнение в той заднице, откуда его вытащили.

Т.е. вы тоже считаете, что менеджер зависимостей для C++ не нужен?

Или нужен?