LINUX.ORG.RU

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

 ,


3

3

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

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

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

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

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

На миллиарда пользователей винды - пользователи дебиана это и есть особенные мазохисты.

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

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

Еще раз - архиватор задействован. Если бы задача заключалась ТОЛЬКО в распаковке, был бы задействован ТОЛЬКО он.

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

а что не так, dpkg вызывает архиватор с правильными ключами, потом вызывает скрипты из распакованного (которые выполняются bash-ем, а не самим dpkg), всё по канонам юникс-вея

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

Конаном не сделаешь один репозиторий, как я понял. То есть у тебя либы L1 L2 L3, L2 и L3 зависят от L1 , в их репах есть конанфайл, потом есть сервис S1 S2 S3 в них тоже конан файл в котором указаны зависимости от либ 2 и 3. Когда обновишь L1 начнётся каскад обновлений.

У никса я сделал один репозиторий, там все файлы никса для всех проектов. В нем достаточно будет указать новую ревизию для L1, дальше все пересоберется само, когда захочешь собрать S1 например (или если консоль запустить для него).

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

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

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

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

А если я ставлю .h файлы, почему я не могу выбрать место в которое их поставить? Может я себе в проект хочу? Любой архиватор позволяет выбрать куда распаковывать. А dpkg нет. Значит, во-первых, это не только архиватор и задача не сводится к распаковке, во-вторых - это перчатко-кувалда, которой и боксировать плохо и ковать.

А все вместе это нарушение юникс-вея.

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

ну дак есть apt, есть aptitude, есть synaptic

Еще круче. И какие разные задачи это все решает? Тут три универсальных жирных инструмента для одной задачи. И все трое машут перчатко-кувалдой под названием dpkg.

Я тебе говорю - у тебя кузнец должен молотом работать, а боксер перчаткой.

А в ответ - ну вот, у меня три бугая куют по морде перчатко-кувалдами. Тремя.

Разницу видишь?

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

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

Распаковка обязательна, скрипты необязательны. Если не нужны, скриптов нету.

А если я ставлю .h файлы, почему я не могу выбрать место в которое их поставить?

А зачем тебе это? Любой путь к .h файлам можно легко указать в параметрах сборки. Особенно если ты их используешь только как зависимости и не шлёшь в апстрим патчи.

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

Ну и когда все .h файлы лежат в одном заранее известном месте - /usr/include — это удобно. Не просто так же это сделали.

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

По поводу линков и .h файлов. Я на cmake скрипт написал, он на этапе сборке смотрит в переменную окружения и либо там ищет указанный файл либо качает его , если в окружении нет. Конаном не сделаешь переменную окружения. Я из окружения часто что нибудь беру, настройки там всякие. Мне всегда хочется чтобы из коробки работало. У никса тупо запускаешь с каким нибудь параметром (ну я делаю специальную опцию, что например дев окружение) и все. На проде скрипт например или интегрируешь никсовое окружение. Главное что при разработке деплоить не нужно.

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

Любой путь к .h файлам можно легко указать в параметрах сборки

Вот именно. Поэтому твой проект будет собираться только у тебя и только сейчас.

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

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

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

Они не лежат прямо в /usr/include.

А сделали это потому что свалить все в кучу - это самое простое. А сначала люди имеют тенденцию делать как им проще.

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

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

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

люди имеют тенденцию делать как им проще.

Так сделай уже вдоль, не мучайся, клоун.

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

Вот именно. Поэтому твой проект будет собираться только у тебя и только сейчас.

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

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

Они и так уже одни в Unix-системе, придерживающейся FHS — в /usr/include

и будут относительными внутри самого проекта

какой-то вендузятский подход

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

излишнее ненужное копирование

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

Они не лежат прямо в /usr/include.

в проект они подключаются относительно /usr/include, с поддиректорией

например

#include <openssl/ssl.h>
Harald ★★★★★
()
Ответ на: комментарий от James_Holden

Они не лежат прямо в /usr/include.

И некоторые таки лежат. Даже скорее многие

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

Отсутствия общепризнанного менеджера пакетов не мотивирует разработчиков клепать библиотеки и нормально их оформлять.

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

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

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

Всё равно проще, чем конпелять эти же зависимости самому.

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

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

А все класть в одну диру не очень - частенько надо разные версии одного и того же.

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

Либо собираешь на такой же .deb системе того же релиза

Прибивать сборку к релизу дистрибутива - это просто днище.

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

Да, а теперь вспомни при помощи чего она это делает. Оказывается, внезапно, что для этого в системе второй «менеджер пакетов» - уже тех самых, которые для разработки. Причем их два - pkg-config и cmake отдельно делают то же самое. И хорошо что делают, если бы эта задача тоже решалась через дергание apt (а технически это легко), то вообще был бы финиш.

какой-то вендузятский подход

В винде обожглись в середине 90-х на dll hell и сразу поняли, что не стоит гадить в систему. Надо сидеть по загончикам. А в линуксе крупная популяция жирафов с шеями длиной 25 световых лет. Сигналы еще не дошли.

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

А все класть в одну диру не очень - частенько надо разные версии одного и того же.

Так не в одну же диру. Ну что за мания все в кучу валить как в /usr/bin. Есть же подпапки :)))

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

Поддиректории не стандартизированы никаким FHS. То есть могут быть любыми.

Зато они явно указаны в документации конкретной библиотеки

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

Всё равно проще, чем конпелять эти же зависимости самому.

Вот поэтому я и хочу менеджер. Я конечно не хочу их конпилять сам. Пусть менеджер конпиляет.

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

Да, а теперь вспомни при помощи чего она это делает. Оказывается, внезапно, что для этого в системе второй «менеджер пакетов» - уже тех самых, которые для разработки. Причем их два - pkg-config и cmake отдельно делают то же самое. И хорошо что делают, если бы эта задача тоже решалась через дергание apt (а технически это легко), то вообще был бы финиш.

скорее

./configure CPPFLAGS="-I myprivateincludes"

или

make CPPFLAGS="-I myprivateincludes"

pkg-config-у самому надо путь к .pc файлам указывать, если он не дефолтный :)

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

А если мне надо иметь две разные версии одной и той же библиотеки в двух разных проектах? Как они в одну поддиректорию станут?

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

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

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

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

Так их приходиться конфигурить отдельно, так что можно хоть куда ставить, не обязательно в /usr/include

А там потом начинается, типа libfoo-1.1 а потом ещё надо две ее версии дебаг и релиз…

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

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

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

Они сконпиляли под свою систему, а у меня своя. А так да, можно и бинарники сразу ставить, рядом с .h файлами.

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

так что можно хоть куда ставить

Ну так в том и проблема.

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

Бинарники могут черте-где лежать.

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

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

логично стремиться

Стремиться - не значит сразу брать и делать. Человечество стремится к звездам, но это не значит что через час вылетаем.

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

в автотулзах для этого специальные макросы есть, AC_CHECK_PROGS например

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

У кого у нас? У меня вообще не deb, я же писал сколько раз что я не мазохист.

Да даже если был бы deb - проблемы те же. deb систем актуальных в данный конкретный момент где-то 5. Все несовместимы.

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

У меня вообще не deb, я же писал сколько раз что я не мазохист.

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

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

Все возможные места нахождения бинарников во всех поддерживаемых тобой дистрах

Я не знаю какие я поддерживаю дистры. И никто не знает. Я поддерживаю линукс а не дистры.

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

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

Я не знаю какие я поддерживаю дистры. И никто не знает. Я поддерживаю линукс а не дистры.

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

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

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

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

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

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

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

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

ну как минимум, процессорное время на конпеляцию ты тратишь, а можно было бы из репозитория поставить

вполне возможно, что эта процедура, повторённая на 5 дистрах, в сумме займёт меньше времени, чем конпеляция всех зависимостей из исходников

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

Значит те поддерживаешь.

Да, но этого недостаточно.

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

Патчи не нужны - должно все работать сразу.

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

Я требую.

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

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

ну как минимум, процессорное время на конпеляцию ты тратишь, а можно было бы из репозитория поставить

Побоку.

вполне возможно, что эта процедура, повторённая на 5 дистрах, в сумме займёт меньше времени, чем конпеляция всех зависимостей из исходников

Мне не надо собирать на 5 дистрах. Надо собирать один раз чтобы работало на всех дистрах.

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

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

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

а как ты будешь следить за обновлениями безопасности всех зависимостей и вовремя уведомлять юзверей, что пора заново качать твой 100500 мегабайтный блоб, ибо в libxyz-123 нашли CVE-56789? :)

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

Мне надо собирать на системе где нет дистрового пакетного менеджера (это не винда если что).

ну тогда MacPorts/HomeBrew

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