История изменений

типовые сценарии сборки С++ несостоятельны без обращения к системе и действий, выполняемых сейчас в скриптах

Например какие такие «обращения к системе» нужны в типовых сценариях сборки, без которых они не состоятельны? И почему нельзя скажем для 90% типовых сценариев сборки предусмотреть декларативный манифест аля Cargo, а оставшиеся 10% специальных случаев так уж и быть, доделывать императивными скриптами, прописанными в декларативном манифесте?

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

Именно. В этом и проблема, что пакетных менеджеров существует целый зоопарк, они не включены в стандарт и каждый из них ущербен по своему, из-за чего три четверти крестовиков так и продолжают пихать зависимости себе в репу. CMake может в сборку, но не может в менеджмент пакетов. Conan наоборот чистый менеджер пакетов, не умеющий в сборку. Meson пытается делать и то, и то, но с таким количеством пакетов ему хотя бы до конана как до луны раком. Остальные поделия еще более маргинальны и малоизвестны. Разительное отличие от стандартизированного Cargo, которым собираются любые крейты в экосистеме раста.

Желаю почаще писать императивные секции декларативных манифестов. Желательно на XML.

Не самый плохой вариант кстати. На оффтопике так и делают испокон веков. Открыл проект в проприетарной студии, натыкал опций в гуйне с настройками проекта, добавил условные конструкции руками в XML-файл, ткнул Build, все собралось. ИЧСХ, это даже как-то работает. Любителям долбиться в императивные скрипты сборки стоит взять на заметку.

Тот самый cabal, который давно сломан и не чинится. Какое отношение, кстати, Haskell имеет к системщине?

Да, это тот самый Cabal, который к версии 3.0 научился в nix-style сборку, починил все проблемы с депенденси хеллом и теперь на световые годы впереди традиционных пакетников. Кабал файл тут просто для примера, как можно сделать if-конструкции в декларативном манифесте. Не все же XML или JSON руками править. Думается, что этот же самый подход прекрасно применим и к С++.

А теперь откровение: в С++ для ho-либ зачастую также не нужна система сборки. Почему-то адвокаты cargo.toml про это регулярно забывают.

С этим да, согласен, но думаю не надо тебе объяснять, что header only либы непрактичны в большинстве случаев. И вообще, я сварщик ненастоящий, на расте вообще не пишу ни разу, я больше топлю за декларативный подход к сборке, а Cargo это только пример, наиболее приближенный к реалиям С++.

типовые сценарии сборки С++ несостоятельны без обращения к системе и действий, выполняемых сейчас в скриптах

Например какие такие «обращения к системе» нужны в типовых сценариях сборки, без которых они не состоятельны? И почему нельзя скажем для 90% типовых сценариев сборки предусмотреть декларативный манифест аля Cargo, а оставшиеся 10% специальных случаев так уж и быть, доделывать императивными скриптами, прописанными в декларативном манифесте?

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

Именно. В этом и проблема, что пакетных менеджеров существует целый зоопарк, они не включены в стандарт и каждый из них ущербен по своему, из-за чего три четверти крестовиков так и продолжают пихать зависимости себе в репу. CMake может в сборку, но не может в менеджмент пакетов. Conan наоборот чистый менеджер пакетов, не умеющий в сборку. Meson пытается делать и то, и то, но с таким количеством пакетов ему хотя бы до конана как до луны раком. Остальные поделия еще более маргинальны и малоизвестны. Разительное отличие от стандартизированного Cargo, которым собираются любые крейты в экосистеме раста.

Желаю почаще писать императивные секции декларативных манифестов. Желательно на XML.

Не самый плохой вариант кстати. На оффтопике так и делают испокон веков. Открыл проект в проприетарной студии, натыкал опций в гуйне с настройками проекта, добавил условные конструкции руками в XML-файл, ткнул Build, все собралось. ИЧСХ, это даже как-то работает. Любителям долбиться в императивные скрипты сборки стоит взять на заметку.

Тот самый cabal, который давно сломан и не чинится. Какое отношение, кстати, Haskell имеет к системщине?

Да, это тот самый Cabal, который к версии 3.0 научился в nix-style сборку, решил все проблемы с депенденси хеллом и теперь на световые годы впереди традиционных пакетников. Кабал файл тут просто для примера, как можно сделать if-конструкции в декларативном манифесте. Не все же XML или JSON руками править. Думается, что этот же самый подход прекрасно применим и к С++.

А теперь откровение: в С++ для ho-либ зачастую также не нужна система сборки. Почему-то адвокаты cargo.toml про это регулярно забывают.

С этим да, согласен, но думаю не надо тебе объяснять, что header only либы непрактичны в большинстве случаев. И вообще, я сварщик ненастоящий, на расте вообще не пишу ни разу, я больше топлю за декларативный подход к сборке, а Cargo это только пример, наиболее приближенный к реалиям С++.