Ускорение сборки проекта на CMake+GCC: предварительная компиляция заголовочных файлов

[alex4e]

Да, в данный момент изучаю ccache, и в целом результаты воодушевляющие. Однако, я бы не сказал, что ccache — это замена precompiled headers. Например, pch может ускорить даже полностью чистую (без кэша) пересборку проекта, поскольку после компиляции pch-файла сборка остальных юнитов будет происходить быстрее. Это может быть полезно, например, для релизных сборок, где хочется быть уверенным в полной повторяемости сборок.

[ABBAPOH]

Начинать стоит с ccache/clcache (или что там сейчас вместо него), так как прирост производетельности огромный по сравнению с PCH. В случае CI на этом можно и остановиться, так как PCH любят «прятать» забытые инклюды.
На машинах разработчиков можно и PCH настроить для пущей скорости.

[eagleivg]

Уже больше года используем в проекте Cotire. Работает даже на древнем CMake 3.5.

Вместе с cotire сборка занимает 7 минут вместо 22 без ccache (с ним чуть быстрее).

[alex4e]

Насколько я понял, с выходом CMake 3.16 Cotire потерял свою актуальность и больше не будет обновляться.

The functionality provided by cotire has been superseded by features added to CMake 3.16. Support for pre-compiling and unity builds is now built into CMake. Thus, there will not be any further updates or support for this project.

[ncr]

Основной минус такого подхода в создании неявных зависимостей. Глядя на исходный файл невозможно сказать, какие именно заголовочные файлы из stdafx.h в нем используются

А какая вам, по большому счёту, разница?
Что даёт знание того, что вот в этом файле используются vector или map?
Если проект хоть немного нетривиальнее "hello, world!", это, скорее всего, так и будет для любого файла.

Я видел достаточно проектов, внедряющих PCH, и почти везде звучало вот это "ой, скрытые зависимости, давайте сделаем сборку без PCH и будем иногда её запускать". И некоторые даже делали. И нет, никто её потом не запускал, потому что были более насущные задачи. В результате зависимостям становилось только хуже.

Расслабьтесь, #include "pch.h" и получайте удовольствие.

[ABBAPOH]

Я видел достаточно проектов, внедряющих PCH, и почти везде звучало вот это «ой, скрытые зависимости, давайте сделаем сборку без PCH и будем иногда её запускать».

Я видел достаточное количество проектов где внедрили pch, и подсветка в половине хедеров была сломана потому что «stdafx.h» включается до всех остальных хедеров.

[Overlordff]

Если так делали специально, то это неправильное использование PCH. PCH не отменяет «самодостаточность» хедеров, просто за ней становится чуть сложнее следить.

[alex4e]

Такой подход по сути навсегда привязывает вас к использованию pch. Если в какой-то момент по какой-то причине вы захотите отказаться от pch — это не так то просто будет сделать.

[Overlordff]

Пройтись по всем cpp и пофиксить ошибки сборки (при том скорее всего большая часть инклудов придёт из парного хэдера, что сократит объём работы). Думаю, за день можно справиться, максимум за три. Сложностей пока не вижу, только время.