Пакетные менеджеры c++

На какие проекты (по размеру) нужно тащить пакетный менеджер?

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

Любой инструмент, в том числе то, что ты называешь «пакетным менеджером», используют не потому что так модно/написано в книге/лектор так сказал, а для решения конкретных задач, т.е. когда без него сложнее, чем с ним. Поэтому, если у тебя не возникло потребности в пакетном менеджере, то он для твоей задачи прям щас не нужен. А если возникла потребность, значит есть конкретные трудности (вот прям щас) которые нужно решить и тогда у тебя таких вопросов не будет, потому что ты не просто знаешь, но уже ощущаешь, для чего тебе нужен этот менеджер (например, у тебя есть несколько проектов, которые используют одну, твою же библиотеку и тебе ее надо как-то включить во все проекты и после ее обновления она должна обновляться во всех проектах).

P.S. Менеджер пакетов в дистрибутиве (apt, yum, dnf) хоть и похож на менеджеры пакетов в C++ (conan, build2, hunter), но решают совершенно разные задачи и использовать менеджер из дистрибутива вместо build2, например, не получится.

Какие признаки, что пора использовать пакетный менеджер?

• Пользователи жалуются, что устанавливать зависимости слишком сложно
• Нужны конкретные версии зависимостей
• Ты не можешь тупо запихнуть проблемные зависимости к себе в репу, потому что они слишком большие, требуют бубен для сборки, имеют другие лицензии, и вообще это некомильфо

Менеджер пакетов в дистрибутиве (apt, yum, dnf) хоть и похож на менеджеры пакетов в C++ (conan, build2, hunter), но решают совершенно разные задачи и использовать менеджер из дистрибутива вместо build2, например, не получится.

Их области применения, скажем так, имеют непустое пересечение, но не совпадают

Их области применения, скажем так, имеют непустое пересечение, но не совпадают

Приведи пример, когда apt можно использовать вместо build2 и я тебе расскажу, почему это не так (ну, или твой пример будет экзотикой, которая возможна только на луноходе или подводной лодке на марсе).

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

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

Смотря какой. Nix для песочницы отлично подходит.

https://conan.io

Смотря какой. Nix для песочницы отлично подходит.

А ну, да. И чё все придумывают пакетные менеджеры? Можно ж использовать nix для всего: и как системный и как менеджер пакетов языка. Хотя постой. Только в песочнице? А в production искать другое решение? Тогда нахрен он такой нужен? Разве что студентам на лабалаторках у оторвавшегося от реальности препода...

Только в песочнице? А в production искать другое решение?

Интересные ты выводы делаешь, чувак. Прямо таки мастер логики.

Так покажи же мне правильную логику. Какие нужно делать выводы из фразы

Nix для песочницы отлично подходит.

И еще: мне насрать на твое задетое самолюбие. Если есть что сказать по делу - говори, а свои понты оставь другим.

Какие нужно делать выводы из фразы

Именно такие, что nix отлично подходит для создания изолированного окружения с отличными от основной системы версиями установленных библиотек. Т.е. для того, что делают менеджеры пакетов, привязанные к языкам. Где ты это будешь использовать — в продакшене или у себя на raspberry pi — это уже от тебя зависит.

И еще: мне насрать на твое задетое самолюбие. Если есть что сказать по делу - говори, а свои понты оставь другим.

Ты задницу-то свою затуши, а то она сгорит совсем.

Приведи пример, когда apt можно использовать вместо build2 и я тебе расскажу, почему это не так

Приложение использует общепринятую библиотеку, скажем openssl или libcurl

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

Песочница != изолированное окружение. И если Nix так хорош, то почему все используют Docker для изолированных окружений, в том числе и для сборки. Может потому что Nix хорош только в твоих фантазиях.

Ты задницу-то свою затуши, а то она сгорит совсем.

И давно тебя интересует моя задница?

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

Если Linux так хорош, почему у всех на десктопах Windows?

И давно тебя интересует моя задница?

Пока она меня не интересует. Но если ты выложишь фото, то всё может измениться.

bazel лучше всего, если есть силы на затаскивание зависимостей в него и лишняя неделя на изучение.
если нужно чтобы быстро и работало - Nix (моя статья на хабре - https://habr.com/ru/post/281611/)
Для embedded есть buildroot, yocto, buildstream.
Остальное можешь не смотреть.
UPD: ах, ну и системный ПМ тоже не стоит забывать - как бы это банально не звучало. Главное смотри на дистрибутивы, которые умеют в distilling пакетов на -dev и -dbg версии.

Приведи пример, когда apt можно использовать вместо build2 и я тебе расскажу, почему это не так

Приложение использует общепринятую библиотеку, скажем openssl или libcurl

Если приложение использует ТОЛЬКО системную библиотеку, причем не openssl, а zlib, например, у которой ни ABI, ни API не менялись много лет, приложение собирается только под Ubuntu, например, тогда вполне (но лучше, как я и сказал, чтобы пакетный менеджер языка использовал системный менеджер). Но вообще, в таком случае, тебе и пакетный менеджер для разработки не особо нужен (только для развертывания, да и то один раз).

Если будет использоваться openssl, а разработчику понадобиться TLSv1.3, то велика вероятность, что системный пакет не подойдет (или разработчик живет под арч, использует возможности библиотеки последней версии и ему насрать, что в production CentOS). Тогда системным пакетным менеджером ты уже не отделаешься.

Если в добавок к openSSL будет использоваться какая-то собственная библиотека, то разработчику при добавлении функциональности придется менять как библиотеку, так и приложение, которое использует эту функциональность из библиотеки и каждый раз собирать пакет из библиотеки (а это лишний шаг и вообще не удобно), чтобы протестировать связку приложение+библиотека. Либо использовать что-то другое, например, пакетный менеджер языка (вариант системный менеджер для системных библиотек и менеджер языка для остального тоже не фонтан).

Я уж не говорю, про случаи когда нужно использовать несколько версий библиотеки или когда нужна поддержка Linux и Windows (про них ты, наверняка, и сам знаешь).

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

IMHO, установка заголовочных файлов системным пакетным менеджером возникла естественным образом из задачи установки программ в дистрибутиве (сначала ставили программы и решили разделить пакеты с библиотеками, используемыми разными программами, затем туда же стали паковать и заголовочные файлы, чтобы собирать программы, зависящие от этих библиотек). И это, наверное, единственный способ сделать, чтобы заголовочные файлы собирались вместе с системной библиотекой (с теми же define и флагами компилятора). Поэтому, если ты пользуешься системной библиотекой, ты обязан использовать заголовки из пакета.

Впрочем, щас все идет к тому, что в системе будет оставаться только совсем системные библиотеки (т.е. те, которые не меняются годами). Все остальное будет поставляться типа модулей в DNF, когда даже в самом древнем дистрибутиве будет идти в том числе и самые последние версии библиотек (системные сами по себе, модульные отдельно). Такой вот способ совместить 10-ти летнюю стабильность с последними повинками (и это в одном дистрибутиве). В RedHat 8 уже завезли. Это то, для чего сейчас используют разные snap и другие костыли.

Есть библиотеки из LSB, там обычно с ABI проблем нет [1]. С остальными можно тупо линковаться статически, всё равно это копейки по сравнению с вебом (и большая часть кода вылетит как неиспользуемая).

[1]:

A.1. libc
A.2. libcrypt
A.3. libdl
A.4. libgcc_s
A.5. libm
A.6. libncurses
A.7. libncursesw
A.8. libpam
A.9. libpthread
A.10. librt
A.11. libutil
A.12. libz
A.13. libnspr4
A.14. libnss3
A.15. libssl3

Есть библиотеки из LSB, там обычно с ABI проблем нет [1]. С остальными можно тупо линковаться статически, всё равно это копейки по сравнению с вебом (и большая часть кода вылетит как неиспользуемая).

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

Если твой ответ в ту же тему, то линковаться статически или динамически с библиотекой, когда она есть в системе по сути без разницы. А когда ее нет, то удобнее иметь инструмент, который к твоему проекту по прописанным зависимостям подтянет другой пакет с этой библиотекой (и опять же будешь ли ты линковаться статически или динамически с RPATH, разница минимальна). Вот этот инструмент - пакетный менеджер языка. Использовать системный менеджер - это костыль, который не только неудобен, но и в большинстве случаев не подходит.

P.S. Я завязываю постить в теме, где ТС ни разу так и не проявился.

Тебе тред для чего нужен, чтоб с ТС'ом пообщаться, чтоле?