LINUX.ORG.RU

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

 ,


3

3

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

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

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

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

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

Зачем мне это делать? Ты так объясни, каким образом подключение сторонней репы обязательно ломает систему. Создатель сторонней репы конечно же может быть рукожопом, но это частный случай. Можно и правильно всё сделать, и ничего не поломается.

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

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

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

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

а как мне в изкоробочном маке установить .h файлы произвольной библиотеки без помощи посторонних пакетных менеджеров? :P

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

Мы с тобой философией занимаемся или решаем конкретные задачи? Я тебе привел пример пакета с которым задача не решается.

значит, у тебя неправильный гнулинукс

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

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

Я тебе привел пример пакета с которым задача не решается.

что тебе мешает опакетить его самому правильным образом?

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

аа, голое ядро без софта, так бы сразу и сказал. Тогда да, поставить .h файлы сложно будет, ядро этого не умеет

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

что тебе мешает опакетить его самому правильным образом?

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

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

А кто тебе сказал что я страдаю??? Мне решение вывалили прямо в первом комментарии. В первом, Карл!

После чего оно было опробовано и интегрировано в процесс. Все. Дальше пошли чисто философские бодания. Технической проблемы давно нет.

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

После чего оно было опробовано и интегрировано в процесс. Все. Дальше пошли чисто философские бодания. Технической проблемы давно нет.

Это пока в репозитории этого вашего conana присутствуют библиотеки желаемых версий. А как только ты захочешь более протухшую, или более свежую, чем там есть, либо нужной библиотеки там не окажется, нытьё про «не хочу опакечивать» начнётся снова.

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

вот я к примеру в репе conan-а не нашёл ffmpeg, всё, говно этот ваш conan, не подходит для разработки, плак-плак

Harald ★★★★★
()

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

Так что увы, только вручную.

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

То что conan фуфло и далеко не идеален я не спорю. Основная претензия - скудный выбор версий.

Пока подходит, потом надо думать.

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

Это для экспериментальной системы, мне тут важно отработать сами принципы.

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

То что conan фуфло и далеко не идеален я не спорю. Основная претензия - скудный выбор версий.

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

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

Нет и не должно быть дистров для разработки.

Только для нее? Да.

Подходящих для нее? Должны.

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

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

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

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

и как из conan-а поставить «последний zita-convolver»?

Сейчас никак.

Так в чём принципиальная разница с репозиторием deb-дистра?

В том что его можно допилить до нужного, а deb нет.

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

У тебя какая-то немотивированная deb-офобия, рвёшься какие-то сторонние васянские пакетные менеджеры использовать, лишь бы не стандартные общепринятые и популярные, по надуманному поводу, что якобы программы и заголовочные файлы нельзя ставить одним ПМ-ом. Странно это всё.

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

У тебя какая-то немотивированная deb-офобия,

Ну неужели я за два дня недостаточно аргументировал свою дебофобию. Не верю.

лишь бы не стандартные общепринятые и популярные

Винда популярная. Давай-ка на ней посиди. Тоже аргумент нашел. Надо использовать правильное а не популярное.

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

Нельзя, это нарушает кучу принципов включая юникс-вей.

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

Ну вот и разрабатывай в арче и сиде, и «деплой» на них же, что бы это не значило.

Странный выбор, конечно, завязываться на такой лютый свежак, но дело твое, может к концу разработки оно уже и в RHEL-10 будет.

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

Ну вот и разрабатывай в арче и сиде, и «деплой» на них же, что бы это не значило.

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

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

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

Нельзя, это нарушает кучу принципов включая юникс-вей.

Когда надо глупость чем-то умным прикрыть, почему-то все вспоминают про UNIX-way.

ПМ занимается сборкой и установкой программного обеспечения. Ставить хедеры 100% его задача.

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

Я не могу разрабатывать в одной системе а работать в другой.

Ну так сделай их одной системой, раз ты такой капризный и ограниченный.

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

Хедеры - это не программное обеспечение. Это текстовый документ. Ты же не ставишь .doc аптом? А почему хедеры надо?

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

Можно написать коллективное письмо к авторитетам юникс-вея и попросить разъяснить, должен ли один и тот же ПМ ставить программы и заголовочные файлы %)

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

Не всё, что было в средневековье, является по умолчанию плохим.

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

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

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

Хедеры - это не программное обеспечение. Это текстовый документ.

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

А ты предлагаешь распространять их мимо ПМа? А кто будет обеспечивать синхронизацию версий? Discoverability? Добычу их непонятно откуда, с теми же дистрибутивными патчами? Санта-Клаус? Охренеть у тебя UNIX-way.

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

А ты предлагаешь распространять их мимо ПМа?

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

Распространять пользователям - это отдельная проблема и ПМ языка ее не решает.

Добычу их непонятно откуда, с теми же дистрибутивными патчами?

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

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

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

А откуда ты знаешь какая задача - моя? Ты думаешь я все проблемы своей жизни в одном треде на ЛОРе излагаю?

Тут обсуждается частная задача. Конечно не создания дистрибутива.

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

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

Ну все, здесь, на границе с миром единорогов и бабочек, я с Вами распрощаюсь. Было… интересно, спасибо!

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

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

А где в нём написано, что должен быть один единственный расово верный дистр?

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

Везде. Один дистр это проще чем сто. Вот и KISS.

CI со сборкой под ворох дистров это дикое нарушение KISS, вместо того чтобы просто собрать софтину ее раскорячивают 10 раз на чуть более разных версиях библиотек. А все почему?

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

Так порождается зоопарк, а потом порождаются адовые костыли типа CI со сборкой под ворох дистрибутивов.

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

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

Ну так и кто запрещает тебе пользоваться слакой?

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

Мне - никто, но мой гордый переход на что-либо не решает мировых проблем.

James_Holden ★★★
() автор топика

@Harald @fernandos

Conan не канает. Как ни грустно - но так.

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

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

Суть проблемы.

Если у нас python + pip то мы имеем стандартный набор модулей голого Python + все остальное можем ставить через pip. То есть вполне реально сделать, и все так делают, внутри проекта virtualenv со всеми, вообще со всеми зависимостями, плюс базовые - будут в самой голой установке питона.

Что-то очень подобное и с npm. В итоге у нас полностью самодостаточный проект.

С C, C++ получается фигня - нет стандартной базы. Что-то может стоять, что-то нет. Еще осложняется тем, что в дебиановых по умолчанию dev пакеты не ставятся. Их надо брать и ставить руками.

И в итоге никакой conan не поможет - он даже не может поставить .h файлы для системных компонентов типа xcb. Их все равно придется ставить пакетным менеджером системы.

То есть тут нужно другое решение.

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