Система сборки для C/C++ c поддержкой VCS

Чем это лучше проверки времени изменения файлов?

Для затравки: https://blog.rust-lang.org/2016/09/08/incremental.html

Нет.

обновление метаданных vcs должно производится после проверки билда на работоспособность, а не перед. С предложенным подходом хлебнёшь горя.

Для C/C++ инкрементальная сборка (с пропуском того, что уже собрано, исходя из неизменности исходного текста и наличия результирующих файлов с бинарным кодом) — очень больная тема. Ибо #include в исходниках совсем не суть модульности, а лишь вставка текста подпрограмм в общую «простыню» текста, подлежащего компиляции. И VCS тут не помогут - только специальные механизмы кэширования, например, CCACHE. Но последний не учитывает флаги компиляции — при их изменении и неизменности исходников всё равно будет произведена компиляция.

Для языка Pascal, например, проблема отслеживания изменений в исходных текстах, раздельная компиляция и инкрементная сборка так остро не стояла и была решена ещё в середине 1980-х, когда реализовали понятие модульности — результирующие файлы .tpu в Turbo Pascal и компоненты из 1990-х-2000-х в Delphi (.dcu).

если бы система собрки могла анализировать данные, предоставленные системой контроля версий

IMHO, это очень плохая идея, особенно в процессе интенсивной правки проекта между коммитами.

Вот, кстати, да. В кресты надо нормальные модули завозить, а не систему сборки к VCS прибивать.

Система сборки для C/C++ c поддержкой VCS

Внезапно, GNU Make.

Т.е. чтобы пересобрать измененный файл придется его закоммитить? No way!

И в каком месте make использует «данные, предоставленные системой контроля версий»?

И в каком месте make использует «данные, предоставленные системой контроля версий»?

Вот в этом: https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html#SEC95

Не, это бы было слишком. В терминах Git можно по просту отслеживать хеш последней сборки (плюс staged/unstaged изменения) до текущего момента (учитывая HEAD, staged, unstaged).

Ну и в конце​-концов я думаю, что информацию с VCS нужно все равно будет дополнять...

В пределах предыдущего проекта я написал такую систему сборки на основе CMake BYPRODUCTS + Git. Идея была в том, чтобы собирать тяжёлые зависимости когда они обновились, но позже переросла и в регулярную проверку зависимостей для обычных проектов. Дело в том, что анализ зависимостей трудоёмкая операция, но полностью перенести все тяжелые зависимости в пререквизиты тоже не получится, поскольку рано или поздно они неявно обновятся и сборка посыпется. Git уже предоставляет индекс и практически мгновенную проверку рабочей директории средствами ФС.

Таким образом у нас, к примеру, автоматически пересобирался Qt и строился сисрут. При пересборке грязной рабочей директории её индекс неявно сохранялся в виде отдельной ревизии (что-то вроде git stash), чтобы не пересобирать при следующем проходе. При сборке сравнивались только 20 байт хеш суммы последней собранной ревизии.

Ещё одна идея, вопрощённая на определённом уровне, это генерация версии собираемого продукта на основе истории Git, чтобы по версии можно было точно идентифицировать ревизию исходного кода, рассыпанного по множеству Git-репозиториев, и переключиться на неё для отладки.

к premake 5 можно пририсовать.

git ничего не знает про unstaged изменения, чтобы из обнаружить он сканирует файловую систему. Да, результат будет точнее чем от сравнениея timestamp в духе make, но с холодным кэшом ФС может быть намного медленнее. Не проще ли взять ccache и не заморачиваться?