LINUX.ORG.RU

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

 


0

1

Доброго вечера, граждане и гражданки.

Есть на гитлабе не большой проект, для себя, для обкатки технологий, показывать стыдно.

В проекте стандартно CMake, библиотека логирования, unit тесты Catch2.

логгирование,unit тесты - лежат хедерами в каталоге include.
Все собирается по хипстерски в docker контейнере, модно-молодежно.
Из пакетных менеджеров работал не много с cargo(привет Rust) и с stack (haskell).

Возникли вопросы следующего характера:

  • На какие проекты (по размеру) нужно тащить пакетный менеджер?
  • Если не нужна кроссплатформенность то хватит простых apt install <пакет с библиотекой> + CMake find_package?
  • Какие признаки, что пора использовать пакетный менеджер?

На хабре есть статья, но тут больше про настройку и проблемы windows.

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

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

Harald ★★★★★ ()

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

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

anonymous ()

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

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

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

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

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hateyoufeel

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hateyoufeel

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

annulen ★★★★★ ()
Ответ на: комментарий от hateyoufeel

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

hateyoufeel ★★★★★ ()

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

snizovtsev ★★★★ ()
Последнее исправление: snizovtsev (всего исправлений: 1)
Ответ на: комментарий от annulen

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

Есть библиотеки из 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

snizovtsev ★★★★ ()
Ответ на: комментарий от snizovtsev

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

LamerOk ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.