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

Знаю conan и vcpkg.

Ну и вот

https://www.jetbrains.com/lp/devecosystem-2021/cpp/#How-do-you-manage-your-third-party-libraries-in-C

.

Просто добавляю всё нужное через git submodule, если у проекта есть официальный общедоступный git. Если нет, то приходится просто кидать исходники в подкаталог.

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

Какой-то чисто виндузятнический опрос. Меня интересует это исключительно в линуксе пока.

conan

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

ЕМНИП, он определяет вашу ОС, компилятор, а потом пытается подтянуть этот пакет, если не выйдет — он соберёт.

Универсальной таблетки нет. Для небольших проектов неплох cget + direnv с настройкой вида

Файл .envrc:

export CGET_PREFIX=`pwd`/cget

Вроде есть ключ –build который принудительно заставляет все собирать.

Отлично, пока это ровно то что нужно.

Я так понял, оно не из репозитория ставит, а надо вручную подсовывать ссылку?

Я и правда в танке ехал.

Все, проблема решена conan. Можно даже qt втыкать (но не нужно).

Да. Но решает проблему добавления не стандартных пакетов .

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

Не люблю когда так делают, проект раздуваться быстро начинает. Все языки в которых так сделали начинают по мелочи всирать десятки гигабайт места в build tree. ALVR (поделие на rust) у меня всрало аж 8 гигов, хотя там нет ничего чему можно занимать много места. про то как node_modules растёт и так все в курсе.
Есть такая функциональность в meson
Ну и есть https://conan.io/

Вот как раз нужно на системе без стандартного пакетного менеджера.

Все языки в которых так сделали начинают по мелочи всирать десятки гигабайт места в build tree

Это лучше, чем то же самое в систему.

conan уже заценил.

Вот и для cmake значит тоже такое есть

Но лучше сабмодулями подцепить нужные версии и интегрировать в систему сборки, так не будет соблазна «СЕЙЧАС Я БУДУ УСТАНАВЛИВАТЬ ВСЕ БИБЛИОТЕКИ»

Тогда, как выше рекомендовали, подмодули - идеальное решение. Тебе все равно нужен git, подмодули можно обновлять автоматически или по необходимости. Ставить - 3-4 строки в файл прописать.

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

Тогда, как выше рекомендовали, подмодули - идеальное решение

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

фу таким быть

cget скорее всего тоже, так что смотри эти 2 варианта. Но я конечно считаю интеграцию в проект предпочтительнее

Nix

Ты не юниксоид. Задумайся - если по канонам юникс-вея «утилита должна делать одну задачу и делать хорошо», то почему ты используешь утилиту «пакетный менеджер» которая делает сразу несколько задач:

1. Установка/удаление/обновление пользовательских приложений

2. Установка/удаление/обновление конфигов

3. Установка/удаление/обновление системных служб

4. Установка/удаление/обновление библиотек для разработки, причем для всех языков сразу!

Это дикое нарушение принципов юникс-вея. Мало того что делается сразу много задач, так еще и все они делаются плохо! А юникс-вей требует делать хорошо.

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

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

Насколько я понимаю, Nix создаст некое подобие контейнера, в котором я могу при помощи Nix поставить все зависимости и вести разработку? Или не так?

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

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

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

Вот статья, мне такой способ немного не подходит, но как введение норм https://habr.com/ru/post/281611/

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

Нет, именно делает одним бинарником. У тебя что, блин, deb пакет с либрой и deb пакет с fftw3-dev ставит разный dpkg? Вот это новости.

Ты вообще представляешь как пакетный менеджер работает?

Запускаешь shell в котором все нужные зависимости уже есть

Вот это и пугает. Мне не нужен шелл, мне нужна IDE которая все видит, и она за пределами «контейнера» и работает в своем отдельном контейнере, где возможности обрезаны.

Для меня важно чтобы менеджер пакетов был один для всего

А для меня - наоборот.

Это не менеджер пакетов, а менеджер окружения.

Ну понятно. Мне нужен просто, и тупо - менеджер библиотек. Даже не назову это пакетами.

Нет, именно делает одним бинарником. У тебя что, блин, deb пакет с либрой и deb пакет с fftw3-dev ставит разный dpkg? Вот это новости.

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

Я юзаю qtcreator, его из нужного окружения запускаешь и все работает. Так в системе даже компилятор не стоит. Ещё visual code работает. Ну частенько тупо в виме сижу.

Я пытался раньше так сделать, чтобы проекты в папке лежали, потом понял что тупиковый путь. У меня проекты множились, выделял библиотеки, переиспользовал их в нескольких проектах. Очень трудно было для каждого подпапку так сделать, не все либы ложатся в такую схему (по началу ок, потом расширяешь проект и облом). Пришёл потом что легче сделать репозиторий deb пакетов. Написал пару скриптов и все дела (ну они проходили по всем нужным дирам, обновляли версии в репе, потом устанавливали новые версии). Такое и для контейнера ок.

Но проще и функциональнее никса ничего не нашёл.

Дело же не в dpkg как таковом. Есть deb пакет, и в нем может быть вот все это вышеперечисленное. То есть один и тот же пакет для всего.

А если разобраться, то задача управления библиотеками для разработчика и задача установки приложений для пользователя - это весьма разные вещи. Разные люди, с разными знаниями, с разными целями. А эти две задачи соединили одним инструментом, который ставит deb пакет.

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

Человеку надо 1) установить приложение 2) установить библиотеку (не как зависимость для приложения из репозитория, а для разработки, с h файлами и исходниками).

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

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

и там файлы распаковываются, и здесь файлы - в чём разница?

потом расширяешь проект и облом

А можно пример такого облома?

и там файлы распаковываются, и здесь файлы - в чём разница?

То есть по твоему у человека когда он сел за компьютер задача - распаковать файлы? Ты даже не понимаешь что в такой постановке вопроса не так?

Поясню - человек плевал на файлы и на распаковку. У него есть задачи, человеческие. Что-то сделать на компе. Распаковать файлы - это не цель человека, это операция при помощи которой машина решает более общую, иную, глобальную задачу человека.

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

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

У него есть задачи, человеческие. Что-то сделать на компе.

Но они все сводятся к скачиванию и распаковке файлов пакетным менеджером

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

или Buildroot

Но они все сводятся к скачиванию и распаковке файлов пакетным менеджером

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

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

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

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

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

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

Это была первая мысль, я и раньше о таком применении portage слышал. Возможно, это и будет решение типа conan.

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

Либо это ты видишь разные задачи, где на самом деле задача одна. Нужно умение обобщать :)

Первое что в голову пришло: сделал для своего проекта веб морду, настроить демона. Хочется чтобы поинтереснее было, а для этого всякие либы фронтовые нужны, плюс статика. Когда разрабатываешь хочется запустить это все прям из директории сборки за один клик, а не деплоить пол часа чтобы посмотреть на новую фичу, а для этого нужно статику положить и запустить сервис. Тесты интеграционные запустить. Гитом можно подпроекты сделать, там будут файлы, приходиться писать скрипты чтобы их от туда доставать и класть куда надо. Потом поизменчешь пару раз, это все становиться очень запутанным.

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

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

Ещё бесит момент: написал либу, используешь ее в трёх проектах например. Потом обновил что нибудь. Надо потом что, по всем проектам идти и руками обновлять? А от тех трёх зависит ещё по два от каждого.. вот именно с такой проблемой столкнулся пару недель назад, там поразвесистее схема была. Нет единого места где решаются такие проблемы (когда на никс перешёл тоже не сразу догадался как сделать там, чтобы это в пару строк решалось).

Вот простой пример твоей логики.

У боксера и кузнеца задачи сводятся к одному - надо бить.

Почему тогда боксер не бьет противнику в табло молотом? Задача, по твоей логике одна.

Потому что надо бить по-разному, разный объект по которому бьют, разная цель, которой пытаются достичь ударом.

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

Что мы и наблюдаем в линуксе. Пользовательские приложения при помощи deb «ковать» фигово - очень неудобно. И людей калечит - повреждает мышление deb религией.

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

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

А чем тут Nix предпочтительнее чем например conan я пока так и не понял.

Задача в твоих примерах сводится к передаче кинетической энергии, т.е. распаковке файлов :)

Более того, что если у тебя задача - распаковать deb как архив, то она решается архиватором ar, а dpkg это нарушение принципа KISS.

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

Пользовательские приложения при помощи deb «ковать» фигово - очень неудобно.

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

Я только про conan слышал. А для эмбедов юзаю platformio.

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

Более того, что если у тебя задача - распаковать deb как архив, то она решается архиватором ar, а dpkg это нарушение принципа KISS.

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

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

Задача в твоих примерах сводится к передаче кинетической энергии, т.е. распаковке файлов :)

Почему боксер и кузнец ее разными инструментами решает?