EL>>Что не так с этими *make кроме названия?
VTT>Выше уже несколько раз об этом писали.
Ничего дельного там не написано об этом, ты просто уходишь от ответа на прямой вопрос. Вот что конкретно не так с CMake?

EL>>IMO все это не нужно если есть нормальный пакетный менеджер
VTT>и если есть добрый дядя, подготовивший подходящий для конкретной системы пакет
Это же можно сказать про репозитории вроде maven-а. Если дядя подготовил то оно там есть, если не подготовил, то нет.

EL>>Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
VTT>Вообще-то второе не имеет смысла без первого.
VTT>Более того, в этом плане у c/c++ имеется фундаментальная проблема:

Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. Вот представь что у тебя есть питоновский пакет, который зависит от конкретной версии какого-нибудь модуля и еще один пакет, который зависит от другой версии того же модуля. Ты не сможешь установить две версии модуля сразу через pip, только используя virtualenv и два разных окружения, что не вариант, если пакеты должны использоваться совместно. Современный пакетный менеджер pip, лол.

В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами.


VTT>В самом языке средств для полного описания прямых и косвенные зависимостей нет, а жесткая привязка к файловой системе есть. Информация о зависимостях (как минимум об их части) и о привязке в файловой системе необходима для осуществления сборки и поэтому присутствует в том или ином виде в сборочных скриптах, но извлечение ее из феерического винегрета этих скриптов обычно крайне затруднено. А перед тем, как приступать к сборке, эту информацию приходится собирать и готовить нужные зависимости. Причем практически всегда вручную. То есть у нас втройне убогая ситуация: одновременно и частичное дублирование информации, и неполнота информации, и необходимость ручных манипуляций.

Если библиотека установлена как положено, то никакой привязки к файловой системе как-бы и нет, оно все всегда сразу находится. CMake тоже не заставляет тебя напрямую работать с именами файлов, находишь зависимость через FIND_PACKAGE и потом просто используешь соответствующие переменные. Я ни разу не делал то, о чем ты тут пишешь "практически всегда вручную" вручную. Оно как-то само получалось

VTT>По факту сборочные скрипты в их нынешнем виде(ах) — это "неуправление" зависимостями.
Вот наверное поэтому они и называются "сборочными скриптами".

VTT>При наличии явного управления зависимостями роль сборочных скриптов заметно упрощается, вызвать исполняемый файл с несколькими аргументами — это дело техники.
Вот о чем я и говорю. Вот как это в винде делается — не знаю, может там все это имеет место быть.