Conan, пакетные менеджеры в С++

Очевидно, что системный менеджер пакетов создан для управления системным ПО, а не для разработки. Например, никому же в голову не приходит использовать apt-get для доустановки jar'ников при разработке на java? Вот для C++ аналогично, из-за убогости (а точнее отсутствия) какой-либо инфраструктуры для него, все городят свои велосипеды, которые обычно сводятся к помойке в виде директории contrib.

вы бы держали свое мнение в той заднице
знают получше вас
закройте рот

Всегда приятно пообщаться с культурным человеком.

Даже не знаю где вы прочитали в моих словах, что пакетный менеджер для С++ не нужен. Попробую ещё одной аналогией: пешеходные переходы для женщин не нужны. Сейчас меня найдут и разорвут феминистки, мол как так, что дорогу могут переходить только мужчины. Хотя и имел в виду, что пешеходные переходы должны быть общими для любого пола.

Даже не знаю где вы прочитали в моих словах, что пакетный менеджер для С++ не нужен.

Да вот же:

Смущает сама постановка задачи: пакетный менеджер C++. Или такой пакетный менеджер будет сам по себе нерабочим без ручной настройки окружения и привинчивания 100500 других пакетных менеджеров под разные ОС, языки, тулчейны и т.д. Или он мутирует в что-то большее, пытаясь перетянуть одеяло на себя.

Отсюда и вопрос про пакетные менеджеры для других языков. Вас они так же смущают?

Остальные языки в большинстве самодостаточны и кроссплатформенны по своей сути, поставив какой-нибудь npm, pip или maven ты получаешь всё нужное для разработки под определённый язык (но это не точно). Окружению же для разработки программ на C++ до самодостаточности далеко как до луны. Шаг в сторону и это выливается в полновесный пакетный менеджер по выкачиванию других языков, жонглированию тулчейнами, системами контроля версий, специфическими системами сборок, статических анализаторов, генераторов документации и прочего прочего.

Остальные языки в большинстве самодостаточны и кроссплатформенны по своей сути

С++ так же кроссплатформеннен по своей сути. И за примерами далеко ходить не нужно.

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

И? Какой из этого вывод?

PS. И это мы еще оставляем за скобками фиерию в роде «генераторов документации и пр».

Про проблемы построения менеджера зависимостей

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

как и системы сборки

С незапамятных времен есть make, automake (тьфу, бяка), autoconf, libtool (тоже не люблю). Недавно появился cmake, который также не вызывает восторгов, но пользоваться можно. Лично мое мнение — если не выходить за пределы Linux, autoconf + make + pkgconfig хватит всем.

C++у нужен свой менеджер зависимостей

Мне не очевидно, зачем нужно сие чудо. Миру C++ нужно больше культуры. О каких зависимостях может идти речь, если народ не понимает разницы между #include <header.hpp> и #include "header.hpp"?

Пусть попробуют поработать те, кто настроены более оптимистично.

Ох, сколько я уже повидал подобных «оптимистично настроенных товарищей». Давай повспоминаем

• autotools говно, нам нужен scons!
• вы все недостаточно кроссплатформенные лохи. bjam is the way to go!
• scons не получился, нужно что-то новое... Давай сделаем cmake!
• нам нужно собирать большие серьезные проекты. Нам нужен bazel!
• make слишком тормозной, мы сделаем ninja!

Это только из того, с чем приходилось сталкиваться. От того, что какие-то бородатые (или прыщавые) товарищи изобретут очередную реинкарнацию cmake ровным счетом ничего не поменяется, потому что эти системы сборок изобретаются не для того, чтобы что-то сделать, а потому что авторы не осилили имеющиеся инструменты (которые, честно скажем, говно за исключением make).

И? Какой из этого вывод?

Диды страдали и нам завещали.

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

Так что, лучше make ничего быть не может?

Лично мое мнение — если не выходить за пределы Linux, autoconf + make + pkgconfig хватит всем.

Вы со своим мнением запросто можете оставаться в пределах Linux-а и мир только обрадуется сему обстоятельству.

Давай повспоминаем

Я могу еще больше вспомнить. Только вот в результате эволюции системы сборок хоть какое-то подобие де-факта стандарта образовалось. И это уже облегчает жизнь множеству C++ разработчиков.

А вот в области систем управления зависимостей еще и конь не валялся.

Только вот в результате эволюции системы сборок хоть какое-то подобие де-факта стандарта образовалось

И что же это за подобие стандарта?

С++ так же кроссплатформеннен по своей сути.

Понятий подмену ощущаю я...

О каком-таком кроссплатформенном C++ идёт речь? Если о стандарте, то он сам по себе безполезен без компилятора, библиотек, выбора ABI, систем сборок, фреймфорков конкретной ОС. И это лишь малая часть при разработке программ, я даже не говорю про кросспомпиляцию под целевую платформу, тестирование, пакетирование, документацию, отладку и так далее.

В современных языках все эти вопросы решают на уровне дизайна самого языка. С другой стороны программы на C++ это конструктор ЛЕГО, в котором собственно сам стандарт это один маленький кубик из коробки на 1024 деталек.

CMake. Подобие де-факто стандарта.

Ощущается явная неспособность говорить по сути. На вопросы хоть хватит мозгов ответить?

Если о стандарте, то он сам по себе безполезен без компилятора, библиотек, выбора ABI, систем сборок, фреймфорков конкретной ОС.

Т.е отличие, например, от Python... ни в чем (да, модули расширения Python тоже зависят от ABI).

я даже не говорю про кросспомпиляцию под целевую платформу, тестирование, пакетирование, документацию, отладку и так далее.

«Тестирование, пакетирование, документация, отладка и так далее» нерелевантны. Единственная новая сущность по сравнению с Python - кросскомпиляция. Насколько я понимаю, в conan она в основном отдана на откуп сборочной системе - autotools и cmake ее умеют.

CMake. Подобие де-факто стандарта.

Очень плохой стандарт. Если нужно что-то сложнее helloworld-а, линкующегося лишь со стандартной библиотекой, начинается закат солнца вручную.

Ни я, ни Dendy (как мне кажется) так не считаем. Я не считаю его строго необходимым, но 100500-й местячковый менеджер тоже не особо нужен. Dendy хорошо описал, что это не решает всех проблем, а те, которые решает, аналогичны другим языкам. И не понятно, почему каждый язык имеет что-то отдельное. Взяли бы pacman (он, вроде, универсальный) или что-то подобное и обобщили между языками, возможно с какими-нибудь плагинами для ЯП-специфичных дел. Ну или подход вроде guix/nix тоже вариант, хоть и не идеальный.

На вопросы хоть хватит мозгов ответить?

Куда мне до такого мастера ведения диалогов.

Так что, лучше make ничего быть не может?

Лучше make может быть только GNU make. А вот чего-то получше GNU make мне пока не встречалось.

Я не об этом тебя спрашивал.

Ну так поясни, что ты имел в виду.

Я сам не в восторге от CMake. Но после того, как его поддержка появилась в основных IDE, огромное количество разработчиков хотят видеть только CMake.

CMake. Подобие де-факто стандарта.

Очень плохой стандарт.

Использую CMake достаточно давно и пока не вижу приемлемых альтернатив. Там многое задумано правильно с точки зрения разработки: управление зависимостями между целями, экспортируемые интерфейсы, конфигурация и кеш, byproducts, различные генераторы сборки (привет, Ninja), инкрементальная сборка и т.д. Но в последнее время чувствуется, что проект упёрся в рамки, за которые без боли не выйти. Это и неполноценные generator expressions, и отсутствие запуска команд с окружением, и ущербный язык.

Для описания сборки больше подходят декларативные языки, тот же qbs на QML. Но в этом и есть свои плюсы разнородного окружения для C++: не нравится одно — заменил другим.

Ну так ответьте на вопросы. А то впечатление, что вы только щеки надувать умеете.

Ну так поясни, что ты имел в виду.

Так что, лучше make ничего быть не может? Я не знаю, как сказать яснее.

Ну так ответьте на вопросы.

Какие вопросы я пропустил? Вообще мне с закрытым ртом сложно отвечать.

Есть две группы программистов. Первой нужен свой пакетный менеджер. Второй - нет. Так вот, мнении людей из второй группы можно просто игнорировать. Т.к. они запросто могут продолжать закатывать Солнце вручную.

Так что, лучше make ничего быть не может? Я не знаю, как сказать яснее.

Можно сделать нечто лучше make, но никто пока не сделал.

Но после того, как его поддержка появилась в основных IDE

Не вижу смысла в IDE. Когда я последний раз ими пользовался, настройка сборки нетривиального проекта требовала ручного указания include и library paths.

огромное количество разработчиков хотят видеть только CMake

На самом деле, они не хотят видеть cmake. Они думают, что это такой генератор проектов для их любимой IDE. А потом появляются проекты, в которых даже install targets не прописаны.

если не выходить за пределы Linux, autoconf + make + pkgconfig хватит всем

Из-за таких как вы C/C++ и ненавидят.

Так что, лучше make ничего быть не может?

Вставлю 2 цента. Проекты уровня «из файла А создать Б», которые призван решать make, канули в лету ещё десятки лет назад. Современные задачи сборки настолько сложны, что для них требуются специальные языки, тот же autotools не от хорошей жизни появился. Тем не менее до сих пор приходится встречать проекты на голых Makefile, которые без поллитры читать нельзя.

Можно сделать нечто лучше make

ВотЪ. А если никто не будет пытаться сделать, то никто и не сделает. Если бы у GNU Make приличный скриптовый язык появился хотя бы 10 лет назад, не было бы вторжения гей-клоунов-убийц из космосазасилья CMake.

Из-за таких как вы C/C++ и ненавидят.

Ты просто не осилил. Я согласен с тем, что нужен более простой autoconf. А вот make и pkgconfig хороши, потому что простые и последовательные.

Зачем мне осиливать некроссплатформенное говно мамонта (autotools/make)?

Любителям писать на локалхосте это конечно не мешает.

Если бы у GNU Make приличный скриптовый язык появился хотя бы 10 лет назад, не было бы вторжения гей-клоунов-убийц из космосазасилья CMake.

Эээ. Из GNU make легко и непринужденно используется bash.

В CMake есть хорошие идеи, но, наверное, ни одна не доведена до конца:

• отдельное дерево для сборки — приходится прописывать пути к бинарнику для запуска ручками, а могли бы таргет run-${TARGETNAME} генерировать
• imported libraries — замечательная идея, но реализация за гранью добра и зла: начиная с того, что в самом ворохе Find${PackageName}.cmake, поставляемых с cmake-ом, imported targets используются, мягко говоря, не везде, и заканчивая тем, что нельзя экспортировать imported targets, поэтому если libfoo зависит от imported library libbar, то все проекты, использующие libfoo будут содержать

  find_package(libbar)
  find_package(libfoo)
  

• кастомные правила сборки — ад и страдание. Я так и не понял, в каких случаях зависимости между custom targets перестают отслеживаться и в protobuf-проектах просто делаю make clean при изменении proto-файла
• невозможность задания своих суффиксных правил GNU make:

  %.gperf.c: %.gperf
    gprof --output-file $@ $<
  
  foo: foo.o foo.gprof.o bar.o
    $(CC) -o $@ $^
  

  CMake: пишешь custom target для каждого такого файла отдельно, либо свой макрос, как в gproto, после чего наслаждаешься некорретно отслеживаемыми зависимостями.
• никакующая поддержка «фич» компилятора: хочешь включить avx или поменять архитектуру генерации целевого кода? Добро пожаловать в set(CMAKE_C_COMPILER_FLAGS "${CMAKE_C_COMPILER_FLAGS} -march=amd64 -mavx")

Если бы у GNU Make приличный скриптовый язык появился хотя бы 10 лет назад, не было бы вторжения гей-клоунов-убийц из космосазасилья CMake.

Эээ. Из GNU make легко и непринужденно используется bash.

Во-первых, интеграции с внутренностями make в этом случае нет вообще; во-вторых, bash не является приличным скриптовым языком - это хороший язык манипулирования файлами, но не более.

В CMake есть хорошие идеи, но, наверное, ни одна не доведена до конца:

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

Зачем мне осиливать некроссплатформенное говно мамонта (autotools/make)?
некроссплатформенный
make

Воу-воу, полегче, ковбой сурового переносимого ржавого энтерпрайза. Иногда лучше подучить матчасть. GNU make есть под windows как минимум в составе cygwin, а под макосями brew install make.

Установить можно, с болью, а вот использовать одни и тот же Makefile для всех ОС уже не выйдет.

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

ППКС. Такими темпами, скоро появится новая система сборки, которая будет генерировать cmake, ибо он слишком убог для понимания нормальными людьми.

отдельное дерево для сборки — приходится прописывать пути к бинарнику для запуска ручками, а могли бы таргет run-${TARGETNAME} генерировать

А с какими аргументами запускать эту программу, в какой рабочей директории? Вот если бы была команда в CMake, в которой можно было бы это перечислить... Хотя постойте: add_custom_target() же.

если libfoo зависит от imported library libbar

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

кастомные правила сборки — ад и страдание.

В CMake всё хорошо с инкрементальной сборкой, если нужна помощь по кастомным правилам — создай отдельную тему, посмотрим.

никакующая поддержка «фич»

Там уже стало получше с target_compile_features() и target_compile_options().

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

Твои бы слова, да авторам CMake в уши. Но похоже они стараются не замечать проблемы, оседлав существующую кодовую базу. Хотя казалось бы кто мешает проделать работу над ошибками, посмотреть на конкурентов и выпустить CMake 4.0, обогнав остальных на одном только имени.

Во-первых, интеграции с внутренностями make в этом случае нет вообще

Лолшто?

SOURCES := src/foo.c src/bar.c src/third_party/baz.c
BUILDROOT := build
OBJ := $(patsubst %.c,$(BUILDROOT)/%.o,$(SOURCES))

.PHONY: makedirs

all: foo

$(BUILDROOT)/%.o: %.c | makedirs
	$(CC) -o $@ -c $<

makedirs:
	# а вот и "интеграция"
	@mkdir -p $(shell echo $(dir $(OBJ)) | tr ' ' '\n' | sort -u)

foo: $(OBJ) | makedirs
	$(CC) -o $@ $^

во-вторых, bash не является приличным скриптовым языком - это хороший язык манипулирования файлами, но не более

Что-то ты заговариваешься. Уж что-что, а с файлами работать в bash та еще боль. Не веришь — попробуй его средствами «прочитать» 20 байт, начиная с 30-го, для произвольного большого файла. Напоминаю, что dd — не часть bash.

использовать одни и тот же Makefile для всех ОС уже не выйдет.

С чего вдруг?

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

А что, уже в каждой ОС есть mkdir, echo, sort, объектники имеют расширение .o, до буквы совпадает командная строка компилятора? И, как я понял, инкрементальная сборка тоже не нужна?

Вот если бы была команда в CMake, в которой можно было бы это перечислить... Хотя постойте: add_custom_target() же.

Хм... Ну если есть cmake --build, то почему нет cmake --run target arg1 arg2 ...?

Это логично

Это логично для тех, кто привык к говнокоду, закатам солнца вручную, а также верит в магические числа, пляски с бубном и злую карму. Когда я пишу pkg-config --libs gtk+-3.0, я не думаю ни об atk, ни о pango — pkg-config «знает» о зависимостях и использует эту информацию.

В CMake всё хорошо с инкрементальной сборкой

Братишка, в cmake все хорошо с инкрементальной сборкой, потому что ее там просто нет. Этим занимается система сборки, для которой cmake только генерирует инструкции. И в случае custom targets, зависящих друг от друга, начинается такое... За примерами можешь проследовать в гугл.

target_compile_features() и target_compile_options()

Второе — костыль, но нужный. Первое — какой-то сферический крестоонанизм в вакууме, поскольку -mavx будешь как миленький прописывать ручками в target_compile_options, поскольку дяденьки в 2018 году не видят причин для создания avx/avx2/и прочих фичей, ведь в их мире живут розовые пони, которым нужны только фичи крестового стандарта.

Во-первых, интеграции с внутренностями make в этом случае нет вообще

Лолшто?

Какое из слов непонятно?

[...]

Ты продемонстрировал манипуляцию ФС. Кто бы мог подумать - bash умеет создавать каталоги.

Напоминаю, что dd — не часть bash.

dd - это часть стандартной библиотеки bash

Ага, специально для тебя я буду расписывать на форуме универсальный кроссплатформенный makefile. К твоему сведению, расширение у объектного файла может быть абсолютно любым. На это даже msvc-шному компилятору и тулзам пофиг.

как я понял, инкрементальная сборка тоже не нужна?

Как я понял, ты не понимаешь, что «инкрементальная сборка», которую тебе продают под видом инновационной IDE-bound фичи, существует в make со времен его рождения. В ninja, кстати, тоже, поскольку их (make и ninja) основная задача — выполнить команду, если целевой файл старше его зависимостей.

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

Какое из слов непонятно?

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

Ты продемонстрировал манипуляцию ФС. Кто бы мог подумать - bash умеет создавать каталоги.

Нет, я продемонстрировал, как некую внутреннюю информацию передать из make в bash — в точности то, что ты хотел.

dd - это часть стандартной библиотеки bash
стандартной библиотеки bash

Так, с этим профессионалом все понятно. У него coreutils — это стандартная библиотека bash. Я, конечно, слышал, что coreutils-ами можно пользоваться из zsh, csh и даже из хипстерского fish, но такому гуру как ты, конечно, виднее.

Хм... Ну если есть cmake --build, то почему нет cmake --run target arg1 arg2 ...?

Я же вроде в посте, который ты комментируешь, ответил на вопрос почему.

pkg-config «знает» о зависимостях и использует эту информацию

Ты же вроде жаловался, что такое же поведение в CMake это проблема, когда импортированная библиотека знает о зависимостях и автоматически их подставляет? Или я неправильно понял?

в cmake все хорошо с инкрементальной сборкой, потому что ее там просто нет

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

поскольку дяденьки в 2018 году не видят причин для создания avx/avx2/и прочих фичей

Есть разница между фичами компилятора и архитектуры. Первое встроено в CMake и они стараются поддерживать флаги в актуальном состоянии. Про второе они уследить не могут, потому что зоопарк архитектур и опций компиляторов огромен. Задача решается созданием интерфейс-библиотеки, которая включается в необходимые цели. Или на уровне тулчейн-файла.

я продемонстрировал, как некую внутреннюю информацию передать из make в bash

Молодец. Теперь передай в bash список правил с командами, поправь его, и импортируй внутрь make.

У него coreutils — это стандартная библиотека bash. Я, конечно, слышал, что coreutils-ами можно пользоваться из zsh, csh и даже из хипстерского fish

И что? Ты не слышал, что стандартной библиотекой Си, например, можно пользоваться из Си++, Python, Rust?

но такому гуру как ты, конечно, виднее.

Внимательно слушай меня и учись.