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

У CMake генерация зависимостей вынесена на этап самой сборки, после этапа конфигурации. То-есть при вызове cmake зависимости C++ ещё не собраны. Они будут самостоятельно обновляться в фоне и никогда не бывают сломаны. Переконфигурация также вызывается самостоятельно и только в случае, когда сами скрипты были потроганы, но не C++ код.

Кроме того, в отличии от вышеописанной проблемы с Makefile, который не хранит историю, CMake таки её хранит и знает с какими параметрами был собран каждый объектник, и если они изменились — он будет пересобран. То-есть проблемы с добавлением define'ов нет. К примеру, в случае с Ninja эти параметры хранятся в файле .ninja_deps и обновляются на лету. С Makefile всё немного замороченей, поскольку из коробки в нём такого нет, то CMake сам сохраняет параметры сборки в отдельный файл.

Мораль — нужно генерировать столько промежуточных файлов, сколько нужно. QMake с его идеологией «сломанный Makefile, зато всего один» — сам себе вырыл могилку.

У CMake генерация зависимостей вынесена на этап самой сборки, после этапа конфигурации. То-есть при вызове cmake зависимости C++ ещё не собраны. Они будут самостоятельно обновляться в фоне и никогда не бывают сломаны. Переконфигурация также вызывается самостоятельно и только в случае, когда сами скрипты были потроганы, но не сам C++ код.

Кроме того, в отличии от вышеописанной проблемы с Makefile, который не хранит историю, CMake таки её хранит и знает с какими параметрами был собран каждый объектник, и если они изменились — он будет пересобран. То-есть проблемы с добавлением define'ов нет. К примеру, в случае с Ninja эти параметры хранятся в файле .ninja_deps и обновляются на лету. С Makefile всё немного замороченей, поскольку из коробки в нём такого нет, то CMake сам сохраняет параметры сборки в отдельный файл.

Мораль — нужно генерировать столько промежуточных файлов, сколько нужно. QMake с его идеологией «сломанный Makefile, зато всего один» — сам себе вырыл могилку.