Comments 11
Используйте ccache и будет вам второе счастье.
+1
Да, в данный момент изучаю ccache, и в целом результаты воодушевляющие. Однако, я бы не сказал, что ccache — это замена precompiled headers. Например, pch может ускорить даже полностью чистую (без кэша) пересборку проекта, поскольку после компиляции pch-файла сборка остальных юнитов будет происходить быстрее. Это может быть полезно, например, для релизных сборок, где хочется быть уверенным в полной повторяемости сборок.
+2
Разумеется ccache не замена. Я же говорю, — второе счастье по тому, что пересборка кода осуществляется чаще, чем его первичная сборка.
0
Начинать стоит с ccache/clcache (или что там сейчас вместо него), так как прирост производетельности огромный по сравнению с PCH. В случае CI на этом можно и остановиться, так как PCH любят «прятать» забытые инклюды.
На машинах разработчиков можно и PCH настроить для пущей скорости.
На машинах разработчиков можно и PCH настроить для пущей скорости.
0
Уже больше года используем в проекте Cotire. Работает даже на древнем CMake 3.5.
Вместе с cotire сборка занимает 7 минут вместо 22 без ccache (с ним чуть быстрее).
Вместе с cotire сборка занимает 7 минут вместо 22 без ccache (с ним чуть быстрее).
0
Насколько я понял, с выходом 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.
0
Основной минус такого подхода в создании неявных зависимостей. Глядя на исходный файл невозможно сказать, какие именно заголовочные файлы из stdafx.h в нем используются
А какая вам, по большому счёту, разница?
Что даёт знание того, что вот в этом файле используются vector или map?
Если проект хоть немного нетривиальнее "hello, world!", это, скорее всего, так и будет для любого файла.
Я видел достаточно проектов, внедряющих PCH, и почти везде звучало вот это "ой, скрытые зависимости, давайте сделаем сборку без PCH и будем иногда её запускать". И некоторые даже делали. И нет, никто её потом не запускал, потому что были более насущные задачи. В результате зависимостям становилось только хуже.
Расслабьтесь, #include "pch.h" и получайте удовольствие.
0
Я видел достаточно проектов, внедряющих PCH, и почти везде звучало вот это «ой, скрытые зависимости, давайте сделаем сборку без PCH и будем иногда её запускать».
Я видел достаточное количество проектов где внедрили pch, и подсветка в половине хедеров была сломана потому что «stdafx.h» включается до всех остальных хедеров.
0
Такой подход по сути навсегда привязывает вас к использованию pch. Если в какой-то момент по какой-то причине вы захотите отказаться от pch — это не так то просто будет сделать.
0
Sign up to leave a comment.
Ускорение сборки проекта на CMake+GCC: предварительная компиляция заголовочных файлов