LINUX.ORG.RU

Установка библиотек C, C++ прямо в проект

 ,


3

3

Есть ли готовые решения в виде менеджера пакетов, желательно source-based, который бы ставил все нужные зависимости не в систему, а в папку проекта?

Желательно чтобы это было кроссдистрибутивно (но интересуют и иные варианты, если нельзя так).

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

Вроде простая задача, и во всяких Node, Python решается штатно, а такой затык. Или я в танке еду и не знаю про очевидные решения. Помогите, кто знает?

Ответ на: комментарий от Harald

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

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

Ну вот аналог этой фигни я и ищу для линукса.

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

Причем их два - pkg-config и cmake отдельно делают то же самое.

CMake отлично умеет дергать pkg-config, так что никакого дублирования не нужно.

Siborgium ★★★★★
()

ставил все нужные зависимости не в систему, а в папку проекта

А если у тебя несколько проектов завязаны на одну библиотеку?

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

А если у тебя несколько проектов завязаны на одну библиотеку?

Я в итоге пришел к conan. В папку проекта - это да, излишне именно по озвученной тобой причине.

conan ставит просто в /home/user/.conan, а в папку проекта генерирует конфиг для cmake, чтобы все подхватывалось. Это меня полностью устраивает - система не модифицируется.

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

Если у твоей IDE есть поддержка direnv, то можно через него окружение пробросить. Я так пробрасываю в Emacs, например

Ну или с просто запустить IDE из шелла, да.

theNamelessOne ★★★★★
()

Полюбому, дурное дело нехитрое.

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

В принципе это неплохо.

Нет, это гадко, отвратительно, регрессивно, неэффективно и небезопасно.

Но хотелось бы еще искать и просто командой install ставить. Как с обычным пакетным менеджером.

Если это уже придумали, то его нужно разпридумать.

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

Нет, это гадко, отвратительно, регрессивно, неэффективно и небезопасно.

В принципе да, согласен. Я так не делал и не буду. Пакетный менеджер конечно лучше, но нужен такой, который управляет библиотеками, а не всей вселенной.

У меня проект, сейчас тупо в инструкциях для сборки на гитхабе написана команда для убунты как поставить все dev пакеты. Это уродство, во-первых только для убунты, во-вторых я не на убунте и могу записать туда не то (и записал, потом чинил по репорту), в третьих очень напряжно выуживать какие пакеты туда записать, в третьих в любой момент в убунте все поменяется.

С conan можно написать файл с зависимостями и в процессе сборки он все поставит в home независимо от дистрибутива, что сильно упрощает задачу. И зависимости не прибиты, как это было бы с submodule.

Если будут собирать deb или другой «классический» пакет - то поставят зависимости пакетами и соберут без conan. А если человек хочет через make, make install - то не надо париться с зависимостями и загаживать систему.

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

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

Забудем на секундочку про Nix.

Что мешает положить в репу deb packaging, в CI собирать пакет и посылать пользователей смотреть в packaging?

Что мешает просто без этого добавить в CI тест, который выполняет apt install из README и проверяет, что этого достаточно?

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

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

Ты пишешь сейчас про деплой, а я про окружение для разработки. Меня пока не интересует деплой. Естественно, что если нужен deb, то тогда неизбежно возникает необходимость все-таки выудить эти deb зависимости и ставить их через apt. И тогда надо делать как ты написал.

Но мне пока не нужен deb, мне пока надо на своей системе вести разработку.

И есть в силу специфики проекта, множество людей которым также не нужен deb, их бы устроил make, make install вполне. Но чтобы его сделать, им надо пакеты своего дистрибутива, у каждого разного, впендюривать прямо в систему.

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

мне пока надо на своей системе вести разработку.

На своей системе поставь все нужное как угодно: пакетным менеджером, его средствами virtualenv, ЯПшными средствами virtualenv, хоть make install, сиди, разрабатывай и не увиливай.

им надо пакеты своего дистрибутива, у каждого разного, впендюривать прямо в систему.

Это проблема каждого первого софтового проекта. Ты знаешь, как она решается. Лучше в обозримом будущем не будет.

Иди, короче, код пиши =)

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

Ну это же костыли-костылики, если говорить уже о деплое.

добавить в CI тест, который выполняет apt install из README и проверяет, что этого достаточно?

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

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

На своей системе поставь все нужное как угодно: пакетным менеджером, его средствами virtualenv, ЯПшными средствами virtualenv, хоть make install, сиди, разрабатывай и не увиливай.

Естественно, я могу сделать как угодно. Я спрашиваю как сделать оптимально.

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

Это ерунда какая-то. Надо остановиться, задуматься и поискать более оптимальные пути решения задачи.

Ну вот зачем мне например make install когда есть conan? А я некоторое время хреначил и не знал про conan.

Ты знаешь, как она решается

Да, знаю. Впендюриванием в хомяк, кроссдистрибутивно в процессе сборки. Или в контейнер, но в данном случае это оверкилл.

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

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

Это ты захотел тестировать содержимое README.

И с какой частотой я должен это делать?

Каждый коммит, CI же.

Кто мне даст гарантию что не отвалится в любой момент?

Никто, смысл тестов в том, чтобы выявлять дефекты.

Ну это же костыли-костылики, если говорить уже о деплое.

Да кто такой этот твой деплой?

Есть задачи апстримного кода. Там и тест содержимого README — оверкилл. Если он, конечно, не способ избежать дублирования того же списка в CI, хм.

Есть задачи пакетирования. 100% завязка на дистр, делается, обычно, отдельно и другими людьми.

Есть деплой. Он в ста километрах к югу от этого всего.

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

Я спрашиваю как сделать оптимально.

Откуда нам знать, что из этого займёт для тебя 3 секунды, что 33, а что невозможно?

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

Это ерунда какая-то. Надо остановиться, задуматься и поискать более оптимальные пути решения задачи.

Теоретически — ты более чем прав. Я вот подумал и делаю из всех своих новых поделок Nix flake. Кто-то другой подумал и родилось богомерзкое для меня и идеальное для него cargo. И т.д.

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

Ну вот зачем мне например make install когда есть conan? А я некоторое время хреначил и не знал про conan.

Чтобы ты и дальше хреначил, не отвлекаясь на решающий 0 проблем conan.

Ты знаешь, как она решается

Да, знаю. Впендюриванием в хомяк, кроссдистрибутивно в процессе сборки. Или в контейнер, но в данном случае это оверкилл.

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

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

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

Не знаю конкретно про cargo, но почему ты считаешь пакетный менеджер языка богомерзким?

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

Богомерзкий cargo или pip на самом деле. Но не сам по себе - проблема в деплое, чтобы не напрягать пятую точку люди просто берут среду, в которой шла разработка и всовывают на целевую систему. Так это отдельная проблема и ее надо решать отдельно.

В реальном мире она решается опакечиванием под каждый дистрибутив отдельно

А как тут Nix поможет? И какая разница тогда чем ты среду разработки делал, никсом или конаном?

Чтобы ты и дальше хреначил, не отвлекаясь на решающий 0 проблем conan.

То есть я должен отвлекаться на решающий 0 проблем make install? не вижу логики. И почему conan решает 0 проблем? Он позволяет ставить библиотеки не модифицируя мою систему, на которой и пакетного менеджера (в обычном понимании) не будет. Это ровно моя задача, и он ровно ее решает. Не больше и не меньше.

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

Зачем сюда приплетать деплой?

Понятия не имею. И не буду, пока ты не расскажешь, что ты под этим словом понимаешь. deploy!= packaging

почему ты считаешь пакетный менеджер языка богомерзким?

Потому что пакетный менеджер языка по построению всегда импотентен и потому не нужен.

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

Что он есть. Им могут люди начать пользоваться.

Почему я должен для такой простой задачи тянуть Nix который решает помимо этого еще и задачи управления межгалактическими полетами?

Не должен. Ставь его средствами своего любимого системного ПМ.

А как тут Nix поможет?

Никак. С чего ты взял, что я предлагаю от всего Nix? Я предлагаю от всего юзать системный ПМ.

И какая разница тогда чем ты среду разработки делал, никсом или конаном?

Как минимум +1 ПМ vs +0 ПМ.

То есть я должен отвлекаться на решающий 0 проблем make install?

Нет, ты пиши код.

И почему conan решает 0 проблем? Он позволяет ставить библиотеки не модифицируя мою систему, на которой и пакетного менеджера (в обычном понимании) не будет. Это ровно моя задача, и он ровно ее решает. Не больше и не меньше.

Потому что проблема, созданная выбором conan вместо пакетного менеджера и решенная conan даёт +1 - 1 = 0 решенных проблем.

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

Я понимаю все что ты пишешь, то есть твою точку зрения на все, но я с этим не согласен.

Я считаю, что проблемой является наделение системного ПМ функциями всего на свете. Смешение задач - установки приложений, управления конфигурацией, организации среды разработки. Это разные задачи (даже если оставим конфигурацию пока в стороне). Почему для них один инструмент? Это нарушение юникс-вея, которое порождает ряд проблем.

Получается, что если мне как пользователю удобно использовать Debian Stable (гипотетически), то есть его ПМ и пакетная база меня устраивает в плане установки пользовательских приложений, я почему-то должен и библиотеки для разработки ставить этим же ПМ и из этой же пакетной базы.

Почему? А если мне надо ставить в home? В opt? Упороться и ставить в проект? LinreOffice и Chrome мне не надо ставить в проект. Логично что такой возможности у менеджера приложений нет. А у менеджера библиотек она быть должна.

Почему я должен использовать только тот набор библиотек, который предлагает системный ПМ? А если они протухли? А целевая система будет - не Debian Stable. Зачем мне тогда вся среда разработки собранная ровно из Debian Stable, только лишь потому что мне как ПОЛЬОВАТЕЛЮ удобен этот дистрибутив (гипотетически, на самом деле нет)?

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

Нет, ты пиши код.

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

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

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

Если твой софт такой замечательный и все текут от него и восклицают «вау!», то наверняка найдётся кто-то, кто опакетит в своё свободное время и поделится с сообществом.

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

А если не замечательный? Орать будем как джигурда на мотоцикле, если любить то по русски?

Что за максимализм 12 летний.

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

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

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

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

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

Нипочему. ПМ должен уметь ставить «не из реп», ставить от юзера, ставить что угодно и куда угодно.

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

и последующего деплоя под все нужные варианты.

Ты услышь уже, что с зоопарком ПМ это невозможно. Никакой условный nginx это решить не может и ты не сможешь, и не надо.

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

ПМ должен уметь ставить «не из реп», ставить от юзера, ставить что угодно и куда угодно.

Одно кольцо чтобы править всеми? Деды предостерегали от этого.

Ты услышь уже, что с зоопарком ПМ это невозможно

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

А за пределами моей машины ты как админ решай как делать, тебе оно виднее.

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

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

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

Одно кольцо чтобы править всеми? Деды предостерегали от этого.

Два, популярное и следующее популярное. Как у ситхов, вроде.

Но пойми, что написание кода предполагает его постоянную сборку и запуск на машине разработчика.

apt install из своего README выполни

А за пределами моей машины ты как админ решай как делать, тебе оно виднее.

s/админ/мэйнтейнер твоего пакета/

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

Два, популярное и следующее популярное. Как у ситхов, вроде.

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

apt

bash: apt: команда не найдена

И что?

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

Давно apt разучился в сторонние репы, локально собранные пакеты и hold? Он, конечно, из импотентных ПМ, но не настолько же.

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

И выполни аналог для твоего системного ПМ

Во-первых он недоступен, во-вторых он управляет установкой приложений. Никаких библиотек с .h файлами у него нет.

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

Ты всегда можешь создать свой deb-репозиторий, собрать и поместить в него пакеты вида 'libпротухшаялиба1jamesholdenedition_3_amd64.deb' для всех зависимостей, которые не присутствуют в репозитории дистра и предлагать пользвателям добавить свой репозиторий, чтобы они могли устанавливать твою прогу и зависимости оттуда.

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

Давно apt разучился в сторонние репы

Он никогда в них не умел. Нельзя использовать сторонние репы не ломая систему. Данная конкретная задача так не решается.

локально собранные пакеты

А собирать их я руками буду? А зачем мне тогда ПМ?

hold

Ломать систему мне не надо.

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

Во-первых он недоступен, во-вторых он управляет установкой приложений. Никаких библиотек с .h файлами у него нет.

как это нет, MacPorts точно .h файлы ставит, я проверял, иначе зачем он нужен

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

и предлагать пользвателям

Да блин ты можешь понять что мы сейчас не обсуждаем «предлагать пользователям»? Мне как работать?

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

Ну так выкинь эту какаху и поставь хотя бы apt.

НА ХРЕ НА???

Почему я должен ломать систему, которая полностью устраивает меня как ПОЛЬЗОВАТЕЛЯ для того чтобы решить ОДНУ задачу из СОТНИ, которые я решаю на компьютере? Ты можешь объяснить?

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

Он никогда в них не умел. Нельзя использовать сторонние репы не ломая систему.

4.2

А собирать их я руками буду? А зачем мне тогда ПМ?

Пакеты собирает ПМ // КО

Ломать систему мне не надо.

Если ты в качестве дистра для разработки выбрал хрень, в которой даже зависимости твои не поставить, то ломать её не надо. Взять аккуратно в двух сторон, раскачать и выкинуть на мороз к медведям.

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

Потому что за время, потраченное на этот тред, уже бы выкинул неадекватный задаче инструмент и поставил бы хотя бы apt. То, что ты в твоём недодистре можешь засорять эфир на ЛОРе его не особо красит. Апгрейднись хотя бы до убунты, а то может и до нормального ПМ.

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

Мне как работать?

sudo port install qt5

к примеру

ставит все библиотеки и .h файлы куда-то в /opt, вот туда и указывай пути препроцессора и линкера :)

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

Если ты в качестве дистра для разработки

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

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

поставил бы хотя бы apt

Да нахрен мне твоя убунта нужна? Я тебе десять раз уже писал, что apt не решает моих задач. Он не позволяет даже поставить нужные версии библиотек.

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