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

Проекты, которые на С++ писать нужно, будут содержать практически исключительно скрипты сборки, а не декларативщину.

Спорно, очень спорно. Скрипты сборки - это крайне однотипные и шаблонные задачи, делающие примерно одно и то же. Не вижу причин, почему большинство типовых сценариев сборки нельзя декларативно описать в каком-нибудь JSON манифесте. Ну вот навскидку:

• Часть кода в скриптах сборки занимается поиском установленных хедеров и либ в сборочном окружении. Например find_package в симейке, который может подтягивать монструозный модуль типа такого. Пакетный менеджер делает этот императивный понос полностью ненужным. Достаточно декларативно описать зависимости в манифесте без всякого скриптования, а пакетный менеджер автоматически выкачает, скомпилит и подключит нужные библиотеки.
• В скриптах сборки часто используются различные препроцессоры и кодогенераторы типа doxygen, moc и т.д. Их можно запилить в JSON манифесте через декларативные правила сборки аля make. Да-да, make декларативен, а не императивен.
• Еще часто используются различные кастомные опции сборки типа BUILD_EXAMPLES=ON. С этим уже посложнее, но в принципе это можно сделать через if-выражения, которые включают/отключают нужные секции декларативного манифеста. Пример из хаскельного cabal-файла: тыц.
• И только если позарез нужна императивщина и одним декларативным манифестом ну никак нельзя обойтись, вот только тогда имеет смысл писать скрипты сборки в виде исключения. Причем не на процедурном CMake, а на самом С++.

Ради интереса прошелся по 10 Most Downloaded крейтам на crates.io: build.rs нашелся только в 4 из них. Ну то есть раст во многих случаях может успешно обходиться без всяких скриптов сборки. Что мешает то же самое сделать в С++?

Проблемы лаб, которые зачем-то пишутся на С++ вместо условного питона, меня волнуют мало.

Хорошая иллюстрация, почему каждый условный питон имеет свой условный PyPI и pip, а крестоилитка в 2к22 так и продолжает надрачивать на генереные портянки баша из автотулзов. И ничего лучшего видимо уже не предвидится.

Проекты, которые на С++ писать нужно, будут содержать практически исключительно скрипты сборки, а не декларативщину.

Спорно, очень спорно. Скрипты сборки - это крайне однотипные и шаблонные задачи, делающие примерно одно и то же. Не вижу причин, почему большинство типовых сценариев сборки нельзя декларативно описать в каком-нибудь JSON манифесте. Ну вот навскидку:

• Часть кода в скриптах сборки занимается поиском установленных хедеров и либ в сборочном окружении. Например find_package в симейке, который может подтягивать монструозный модуль типа такого. Пакетный менеджер делает этот императивный понос полностью ненужным. Достаточно декларативно описать зависимости в манифесте без всякого скриптования, а пакетный менеджер автоматически выкачает, скомпилит и подключит нужные библиотеки.
• В скриптах сборки часто используются различные препроцессоры и кодогенераторы типа doxygen, moc и т.д. Их можно запилить в JSON манифесте через декларативные правила сборки аля make. Да-да, make декларативен, а не императивен.
• Еще часто используются различные кастомные опции сборки типа BUILD_EXAMPLES=ON. С этим уже посложнее, но в принципе это можно сделать через if-выражения, которые включают/отключают нужные секции декларативного манифеста. Пример из хаскельного cabal-файла: тыц.
• И только если позарез нужна императивщина и одним декларативным манифестом ну никак нельзя обойтись, вот только тогда имеет смысл писать скрипты сборки исключения. Причем не на процедурном CMake, а на самом С++.

Ради интереса прошелся по 10 Most Downloaded крейтам на crates.io: build.rs нашелся только в 4 из них. Ну то есть раст во многих случаях может успешно обходиться без всяких скриптов сборки. Что мешает то же самое сделать в С++?

Проблемы лаб, которые зачем-то пишутся на С++ вместо условного питона, меня волнуют мало.

Хорошая иллюстрация, почему каждый условный питон имеет свой условный PyPI и pip, а крестоилитка в 2к22 так и продолжает надрачивать на генереные портянки баша из автотулзов. И ничего лучшего видимо уже не предвидится.