Эффективное совместное использование предварительно скомпилированных заголовков

Question

У меня есть фреймворк, который используется несколькими проектами (который включает несколько примеров, чтобы показать, как работает фреймворк). Фреймворк имеет такие компоненты, как ядро, графика, физика, графический интерфейс и т. Д. Каждый из них представляет собой отдельную библиотеку. Также есть несколько конфигураций.

Основной файл решения компилирует полный проект со всеми возможными конфигурациями, чтобы проекты могли использовать библиотеки. Поскольку фреймворк редко перекомпилируется, особенно кем-то (включая меня), работающим над проектом, использующим фреймворк, имеет смысл предварительно скомпилировать множество заголовков.

Изначально у каждого проекта / образца был свой предварительно скомпилированный заголовок, используемый для всего проекта. Каждый раз, когда мне приходилось перестраивать один и тот же pch (например, Debug), я решил, что общий PCH уменьшит избыточную компиляцию PCH. Все идет нормально. У меня есть проект, который компилирует PCH вместе с библиотеками. Все последующие проекты / образцы теперь используют один и тот же PCH. Это сработало чудесно.

Единственная проблема в том, что я видел увеличение размера файла. Это не препятствие, так как если проект, использующий инфраструктуру, предназначен для выпуска, он может отделить себя от общего PCH и создать свой собственный. Я сделал это ради быстрой разработки (я фактически создал инструмент, который создает файлы проекта VS и исходные файлы для нового проекта / образца, готового к сборке, а также облегчает обновление предыдущего проекта, в котором использовался более старый версия фреймворка).

В любом случае (я предполагаю, что) увеличение размера файла связано с тем, что независимый файл проекта VS, который создает общий PCH, включает в себя все заголовки из всех библиотек. Мой вопрос: могу ли я использовать условную компиляцию (#ifndef), чтобы уменьшить размер конечного исполняемого файла? Или, может быть, как-то обмениваться несколькими файлами PCH (насколько я знаю, это невозможно, но я, возможно, ошибаюсь). Если у меня нет смысла, пожалуйста, скажите так (в виде слов :)), поскольку мои знания о файлах PCH очень ограничены .

Спасибо!

Примечание. Чтобы повторить и прояснить ситуацию, у меня пока есть один файл решения, который компилирует все библиотеки, включая общий PCH. Теперь, если я перекомпилирую все сэмплы и проекты, они компилируются не более чем за пару секунд или больше. Раньше каждый проект воссоздали файл PCH. Кроме того, изначально я хотел PCH для каждой библиотеки, но потом я обнаружил, что исходный файл не может использовать несколько файлов PCH, поэтому эта опция была неосуществима. Другой вариант - скомпилировать все возможные комбинации файлов PCH, но это слишком трудоемко, громоздко и подвержено ошибкам.

Answer 1

Похоже, проблема размера связана с использованием заголовков, которые вам на самом деле не нужны, но все же имеет смысл использовать эти заголовки при разработке из-за более быстрого поворота.

Вкл. с использованием #ifndefs: Предварительная компиляция сырая. Вы теряете возможность делиться работой перед компиляцией в той точке, где есть разница. Если вы используете #ifndefs для создания разных вариантов того, что вы включаете, т.е. если у вас есть

#ifndef FOO

Тогда прекомпилированный заголовок должен остановиться до точки, в которой FOO определяется по-разному в двух файлах, которые используют этот предварительно скомпилированный заголовок. Так что #ifndef не решит проблему. В результате FOO должно быть одинаковым, или вы вернулись к отдельным файлам pch для разных проектов. Ни один не решает вещи.

Что касается совместного использования нескольких файлов .pch: Основным ограничением файлов .pch является то, что каждый .obj может использовать только один. Конечно, файлы .pch могут иметь произвольные комбинации заголовков. У вас может быть .pch для ядра + графика, .pch для ядра + физика, ядро ​​+ ai и т. Д. Это будет работать просто великолепно, если ни один из исходных файлов не понадобится для «общения» с более чем ядром + одним модулем на время. Это не звучит реалистично для меня. Такая схема и варианты на ней звучат как большая работа по реструктуризации без реальной выгоды. Вы не хотите создавать миллионы комбинаций и отслеживать их все. Это возможно, но это не сэкономит ваше время.

На мой взгляд, вы делаете совершенно правильные вещи, жертвуя размером исполняемого файла для быстрого оборота во время разработки / отладки, а затем располагая более медленным, но более медленным способом построения для реального выпуска.

Answer 2

В прошлом я обнаружил, что вы довольно быстро сталкиваетесь с уменьшением отдачи, когда вы добавляете больше в предварительно скомпилированные заголовки, поэтому, если вы пытаетесь добавить больше, чтобы сделать его более полезным в большем числе проектов, попадет в точку, которая замедляется. В наших проектах файлы PCH компилируются дольше, чем большинство исходных файлов, но все же максимум несколько секунд. Я бы предложил сделать файлы PCH специфичными для каждого проекта, который вы используете. Вы правы, говоря, что исходный файл может ссылаться только на один файл PCH, но один из способов обойти это - использовать опцию «принудительное включение» (я думаю, во вкладке «Дополнительно»), чтобы все файлы включали PCH. файл для этого проекта.