Мб есть альтернативы круче?

Обычно хватает системного менеджера пакетов.

Если нужен ПМ - то лучше бежать от С++.

Мб есть альтернативы круче?

nix некоторые предлагают как пакетный менеджер для C++, там пакетов много. Если оффтопик не нужен, то вариант.

смирись, будет конан

Объясните глупому...

(Знаю что буду уворачиваться от помидоров. но всё-же)

А приведите, пожалуйста, пример, когда пакетный менеджер для C++ нужен?

Почитал Getting started на docs.conan.io. Судя по всему оно при сборке определяет есть ли установленные зависимости, и, если нет - скачивает. Но ведь это делает тот же portage (пакетный менеджер Gentoo) да и по идее вообще пакетный менеджер любого source-based дистрибутива. Притом в conan какие-то сервера, рецепты, таблицы бинарников под архитектуры, тогда как в Gentoo нет всех этих сложностей.

Или я чего-то не понял?

Мб есть альтернативы круче?

Альтернативы есть, да. Лучше или не лучше - ХЗ: lal, build2.

Но ведь это делает тот же portage (пакетный менеджер Gentoo)

Gentoo? Что такое Gentoo и почему нам должно быть не пофиг?

Или я чего-то не понял?

Ты просто троллишь.

Ты просто троллишь.

Я тоже считаю, что дженту отличная система для разработчика.

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

Ну вот и первый помидор...

Но ведь это делает тот же portage (пакетный менеджер Gentoo)

Gentoo? Что такое Gentoo и почему нам должно быть не пофиг?

Ок, переформулирую вопрос. Правильно ли я понимаю, что для тех, у кого Gentoo, вопрос пакетного менеджера для C++ не стоит? А вместо него может использоваться нативный пакетный менеджер Gentoo?

Или я чего-то не понял?

Ты просто троллишь.

Вот нет, честное слово. Пытаюсь понять.
Ну глуп, Ваше Сиятельство (C).

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

Как и Линуксом, судя по статистике...

Правильно ли я понимаю, что для тех, у кого Gentoo, вопрос пакетного менеджера для C++ не стоит? А вместо него может использоваться нативный пакетный менеджер Gentoo?

Не знаю. Думаю, что не может.

Пытаюсь понять.

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

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

Как и Линуксом, судя по статистике...

Не знаю, где ты взял эту статистику. Линуксом, в отличие от «дженты», пользуются. И как целевой системой, и как инструментальной.

Пакетные менеджеры в Си или С++ не нужны. Я считаю, это хорошо что никто не даёт возможность разводить dependency hell. А то накурятся своего джаваскрипта, а потом десять тысяч зависимостей у проекта, которые 2 + 2 складывают.

Правильно ли я понимаю, что для тех, у кого Gentoo, вопрос пакетного менеджера для C++ не стоит? А вместо него может использоваться нативный пакетный менеджер Gentoo?

Не знаю. Думаю, что не может.

Почему ты так думаешь, не разъяснишь?
Общий формат для тех, у кого не Gentoo - принимается. Еще что-то?

Крайности такие крайности. Но вот сравним vim и emacs - в vim'e каждый заного изобретает gui элементы а в emacs все переиспользуют melpa пакеты.

А потом, поищем темы про библиотеку логгирования на c++ хотя бы на этом отдельно взятом форуме :)

Я тоже когда-то интересовался, дочитал до момента:

 include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
 conan_basic_setup()

После чего закрыл и забыл. Разработчики якобы заявляют про build system agnostic, но при этом в тривиальном примере хардкод и прибитие гвоздями проекта к конану. То-есть после подобной правки проект естесственно нигде кроме конана собираться не будет. Если я неправильно понимаю этот пример, то сие вина исключительно разработчиков данной системы, которые хотят сварить борщ в моей голове.

В принципе, хорошая идея по управлению зависимостями реализована в bitbake, но он тормозной, сложный и нигде кроме Линукса не работает.

Какие там ещё модные молодёжные системы есть на рынке? Gradle, который мутировал в нечто несуразное со своим демоном и отжиранием гигабайтов ОЗУ. В самом CMake впилили ExternalProject, но это как костыль к костылю.

а потом десять тысяч зависимостей у проекта

Эээ, тут явное непонимание разницы между зависимостями и системой их управления. Поясню: зависимость у проекта уже есть, и если автор решил для 2+2 взять какой-нибудь libfixmath, то это абсолютно нормально. Разница только в том, будет ли автор качать сам и просить остальных все эти зависимости, руками настраивать сборку каждой под все необходимые платформы, потом склеивать это в некий сисрут или городить свою доморощеную систему. Или отдаст это на откуп какой-нибудь готовой системе, которая сделает это за него.

В принципе, я за классическое разделение на сисруты и системе поиска в них пакетов тем же CMake, pkgconfig и иже с ними. И отдельно система, которая этот сисрут подготовит и будет поддерживать, как, например, сделано в OE.

в vim'e каждый заного изобретает gui элементы

Чё?

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

Ну, за уши можно vimfiler притянуть, но Shougo слегка наркоман.

Сборщик сисрута — нужно. Поиск зависимостей по pkgconfig — нужно(потому что сисрут). Не нужно, чтобы с проектом выкачивалось несколько много гигабайтов его зависимостей. И я видел такое в других языках. Сходу — вон джава с их Maven. Я вбиваю gradlew debug в консоли и жду полчаса, пока скачается сам гредл, потом гредл выкачает 100500 больших библиотек, которые используются на 10% от силы.

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

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

Ок, дерева нет. List'а с курсором - еще добавлю - тоже нет. Но ведь это требуется в редких случаях. Основные вещи-то есть - окна, табы, completion menu.
Ты так написал, будто вообще ничего нет.

Классная система, наверное.

Нормальная.

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

Почему вам жаль? И что мешает ею пользоваться?

Какие там ещё модные молодёжные системы есть на рынке?

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

Почему языковые пакетные менеджеры популярны для всяких js и php? Потому что ничего важного для них не паписано. А тогда зависимостями и содержимым пакетов можно вертеть как угодно и устраивать адъ.

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

Какая-то перепись утят...

Сейчас тема менеджеров зависимостей для C++ очень горячая. Между собой борются: buckaroo, build2, cget, conan, conda, cpm, cppan, hunter, vcpkg. Это только те, названия которых мне на глаза попадались. Самый распиаренный, по-моему, conan. Насколько заслуженно — хз.

Плюс к этому активно используются: CMake-овский ExternalProject_Add, git submodules (subtree) и всяческие самодельные велосипеды.

Для тех, кто может себе позволить сидеть только под одним конкретным Linux-ом, macOS или FreeBSD, ситуация проще — тут кроме «родных» пакетных менеджеров может ничего и не потребоваться.

Если подытожить - есть то, что сделал автор из коробки.

Отсутсвие выбора - есть хуже чем его наличие.

Ради фана можно вот cargo приучить плюсовый код собирать

Только зависимости он всё равно не качает.

Правильно ли я понимаю, что для тех, у кого Gentoo, вопрос пакетного менеджера для C++ не стоит? А вместо него может использоваться нативный пакетный менеджер Gentoo?

Не знаю. Думаю, что не может.

Почему ты так думаешь, не разъяснишь?

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

Общий формат для тех, у кого не Gentoo - принимается. Еще что-то?

Еще, как бы это сказать, «локальный». Не требующий полномочий суперпользователя и не загрязняющий систему.

Почему языковые пакетные менеджеры популярны для всяких js и php?

У Java есть Maven, у Python - pip, у Ruby - gem, у Go тоже что-то свое. Только у Си/Си++ ничего сиандартного нет.

Потому что ничего важного для них не паписано.

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

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

Все эти conan - попытка скрыть говнокод в зависимостях по образцу javascript. К тому же, плохо совместимая с экосистемой linux. Кому это надо кроме говнокодеров?

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

И каким образом в таком сценарии зависимости будут разрешены? Через libastral?

Ну наконец-то и для плюсов появился менеджер зависимостей!

И не один!

Они давно были, просто в C/C++ слишком много вариантов сборки чтобы удовлетворить всех.

Для полного счастья нужен один, официальный

Для полного счастья нужен еще один

/fixed

Пользуюсь системными менеджерами пакетов: apt, zypper, pacman, vcpkg, pkg

Не понимаю зачем нужен сторонний, если есть системные?

Или тем что он будет один под разные системы? Всё равно не ясно...

Так с менеджерами есть выбор. Только из говна и говна выбрать нечего. Ну не подходит эта концепция.

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

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

Я могу привести пример. У нас на фирме крутится Conan для одного из проектов. Проект кроссплатформенный (да-да, и для винды). Поднят свой conan_server, оттуда conan качает пакеты для проекта, всё это дело подтягивается CMake'ом b и все довольны.

К сожалению, не Gentoo единой - в мире и другие ОС есть.

Только conan, по сравнению с cargo, - УГ.

Google-test есть, поищи лучше. gmock тоже в комплекте имеется.

Подводные камни от меня - не так много пакетов (что-то около 60 пакетов), как хотелось бы (но над этим сейчас активно работают, в том числе и bincrafters).

Новые пакеты появляются часто.

Альтернатив круче лично я не нашёл пока что. Из наиболее популярных есть cppan и vcpkg (который от Microsoft и который уже научился кое-как под линухами работать).

Какие минусы? Сразу хочу сказать - я с cargo не работал. Был бы крайне благодарен узнать сравнение.

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

А как там на винде подтягивать зависимости в проект, не подскажете?

А то, что разработчики тянут зависимости для «2 + 2» - это не пакетный менеджер виноват, а безалаберность разработчиков, не более.

но над этим сейчас активно работают

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

Никто не мешает завести в CMakeLists.txt отдельную опцию для сборки с Conan. И тогда если пользователь выбрал режим сборки без Conan, то всё прекрасно соберётся.