Вот пример из аура https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nlohmann-json-git

Сборка смаком, установка через make install

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

а что, похоже на рецепты конановские

Но это простой пример

ну хедер онли, понятно

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

Мне теперь проще после обновлений либ пересобрать их вместе со всеми зависимостями дабы проконтролировать, что никто ничего не поломал, при необходимости поправить спеки/контролы, сделать при необходимости upgrade/refresh и спокойно работать дальше. В особо запущенных случаях добавить soname

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

А т.к. у меня ещё очень часто в проектах куча всего, что лезет в конфиги системы, systemd, ядро и т.п. то мне удобнее именно линуксовые пакеты, чтобы за 1 команду и либы обновить и правильным образом подготовить систему под эти обновления, чего конан обеспечить не может

Скорее на дебхелпер похоже

Вот побольше скрипт https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glibc . Почти все - возня с _FORTIFY_SOURCE, копирование файлов и проставление симлинков

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

При этом там достаточно много заброшенных пакетов, и проблему несовместимости зависимостей он по факту не решает, что разумеется не забота разработчика библиотеки per se

Эту проблему, к сожалению, ничто не решает
Садишься собирать маленькую либу, а потом выясняется, что надо ещё с десяток либ обновлять :)

А спеки всё равно самые няшные
https://build.opensuse.org/package/view_file/home:mfriesenegger:branches:server:http/opentracing-cpp/opentracing-cpp.spec?expand=1

М, проценты. Флекс замешан?

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

Вот если бы в конан добавили:
1. какую-нибудь фичу, чтобы можно было некоторые пакеты ставить из системной репы, например, какой-нибудь libudev-devel. systemd-devel и т.п. Ибо нефиг такое держать в конане, всё равно по итогу будет юзаться системная либа.
2. Запуск тестов немного более адекватным,
3. Убрали бы совсем conan_basic_setup() или заменили бы на что-то, что не позволяло бы прибивать проект гвоздями к конану ибо это ппц
4. Добавили бы возможность легко пересобирать всё, что зависит от измененного пакета, дабы избежать проблем, когда в проекте X прописана зависимость от проекта Y в виде: >=version_number, а в новой версии проекта Y что-то поломали, в результате чего перестал собираться проект X и другие проекты, зависящие от Y

то, была бы неплохая софтина. А для винды она была бы вообще шикарна.

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

Так что пока конан очень не торт (иначе говоря, говно) особенно для линуха

Не про доставку, но в своем текущем виде он добавляет гемора при доставке благодаря стараниям разрабов с их conan_basic_setup. Так как если уж мы организуем для проекта корректный деплой, то в чем вообще смысл держать для линукса зависимости в конане, если в итоге все равно придется собирать в нормальные пакеты? В плане удобства настройки окружения, что conan update ..., что zypper in ... или apt install ... Наверное, если бы я не был мейнтейнером, то я бы сказал, что конан норм, но увы, мне нравится, когда в системе соблюдается порядок и я не хочу надеяться на то, что найдется мейнтейнер, который соберёт мои проекты. И для меня жизненный цикл ПО не заканчивается на этапе: "у меня все собралось". Если для вас на этом этапе все закончилось, то очень жаль. У конана сейчас единственная фича, что он есть под виндой, где ПМ совсем отсутствует. Да и все зависимости для работоспособности некоторых проектов, в текущую реализацию конана все равно не впихнуть и всё равно иногда надо поковыряться с настройкой окружения и скриптами (чего можно избежать при опакечивании зависимостей). Так что имхо, Конан это "стильно, модно, молодежно", но в своем текущем виде не торт и подходит только для эксплуатации под виндой. Да, там все проблемы можно поправить, если написать свои костыли, но инструмент должен быть удобным.

Поставил линукс

Ubuntu 19.10?

Генту