LINUX.ORG.RU

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

 ,


3

3

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

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

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

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

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

В том плане что если я собираю например GUI приложения в GUI среде то совсем хреново тянуть xcb в «папку проекта». Хедеры - можно, а сама библиотека в системе лежит, раз уж я в GUI среде.

А «несистемные» - это всякая побочка типа zita-convolver, которой в нормальной дефолтной системе нет.

Проще говоря, тут такая лажа. С python + pip я могу ставить все в проект через pip, а в систему питоновские пакеты вообще не пихать. С C/C++ это можно лишь теоретически, практически это выливается в бессмыслицу, потому что любое GUI приложение потянет кучу зависимостей которые и так уже есть в системе. А пакетный менеджер языка типа conan не умеет искать и выделять то, что уже есть и ставить для этого только хедеры нужной версии. По понятной причине не умеет.

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

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

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

надо же, оказывается устанавливать все зависимости «в папку проекта» уже не такая хорошая идея, оказывается половину всего существующего опенсорса собирать самостоятельно придётся :)

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

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

оказывается устанавливать все зависимости «в папку проекта» уже не такая хорошая идея

Эта идея была не для обычного линукса, естественно. Для той структуры системы, для которой я это хотел это хорошая идея и там проблем нет, потому что есть SDK.

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

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

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

ты наркоман? причем тут дистры? нет никаких дистров! есть только ЯДРО, системуде и пакетный менегер, остальное роли не играет

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

есть только ЯДРО, системуде и пакетный менегер

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

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

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

Деление на системные и прикладные библиотеки слишком условное и абстрактное, нет чёткой грани между ними.

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

Ну в линуксе условно, конечно. (В винде с этим проще). В том и проблема что нет четкой грани - поэтому ПМ системы стремится ставить все, и ПМ языка тоже. И если ПМ системы может с этим справится по определению, на то он и «системы», то ПМ языка тут постигает неудача.

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