Compartir encabezados precompilados de manera eficiente

Question

Tengo un marco que está siendo utilizado por varios proyectos (que incluye varias muestras para mostrar cómo funciona el marco). El marco tiene componentes tales como núcleo, gráficos, física, gui, etc. Cada uno es una biblioteca separada. También hay varias configuraciones.

Un archivo de solución principal compila el proyecto completo con todas las configuraciones posibles para que los proyectos puedan usar las bibliotecas. Como rara vez se vuelve a compilar el marco, especialmente si alguien (incluido yo) trabaja en un proyecto que utiliza el marco, tiene sentido precompilar los muchos encabezados.

Inicialmente tenía cada proyecto/muestra tiene su propio encabezado precompilado utilizado para todo el proyecto. Cada vez que tendría que reconstruir el mismo pch (por ejemplo, Debug), decidí que una PCH compartida reduciría la redundancia de la compilación de PCH. Hasta aquí todo bien. Tengo un proyecto que compila el PCH junto con las bibliotecas. Todos los proyectos/muestras posteriores ahora usan el mismo PCH. Esto ha funcionado maravillosamente.

El único problema es que he visto un aumento en el tamaño del archivo. Esto no es un obstáculo, como si un proyecto que utiliza el marco está destinado a ser lanzado, puede separarse del PCH compartido y hacerlo suyo. He hecho esto por el bien del rápido desarrollo (de hecho, he creado una herramienta que crea los archivos del proyecto VS y los archivos fuente para un nuevo proyecto/muestra listo para ser construido así como para facilitar la actualización de un proyecto anterior que estaba usando un versión del marco).

De todos modos, (supongo que) el aumento en el tamaño del archivo se debe a que el archivo de proyecto VS independiente que está creando el PCH compartido incluye todos los encabezados de todas las bibliotecas. Mi pregunta es si puedo usar la compilación condicional (#ifndef) para reducir el tamaño del ejecutable final. O tal vez compartir varios archivos PCH de alguna manera (hasta donde sé, eso no es posible, pero quizás esté mal) Si no tengo sentido, dígalo (en palabras amables :)) ya que mi conocimiento de los archivos PCH es muy limitado. .

¡Gracias!

Nota: Para volver a iterar y dejar en claro, hasta ahora, tengo un archivo de solución que está compilando todas las bibliotecas, incluida la PCH compartida. Ahora, si recompilo todas las muestras y proyectos, compilan en un par de segundos o más como máximo. Antes, cada proyecto recrearía un archivo PCH. Además, inicialmente quería una PCH para cada biblioteca, pero luego descubrí que un archivo fuente no puede usar varios archivos PCH, por lo que esta opción no era factible. Otra opción es compilar todas las combinaciones posibles de archivos PCH, pero eso es demasiado lento y engorroso, y propenso a errores.

Answer 1

Parece que el problema de tamaño proviene del uso de encabezados que en realidad no necesita, pero que todavía tiene sentido utilizar estos encabezados cuando se desarrolla debido a la mayor velocidad de rotación.

En usando #ifndefs: La precompilación es cruda. Pierde la capacidad de compartir el trabajo de precompilación en el punto donde hay una diferencia. Si usa #ifndefs para hacer diferentes variantes de lo que incluye, es decir si tiene

#ifndef FOO 

A continuación, el encabezado precompilado debe detenerse antes del punto donde FOO se define de manera diferente en dos archivos que utilizan ese encabezado precompilado. Entonces #ifndef no va a resolver el problema. El resultado neto es que FOO debe ser el mismo o vuelves a separar archivos pch para los diferentes proyectos. Ninguno resuelve las cosas.

Como compartiendo múltiples archivos .pch: Una limitación fundamental de los archivos .pch es que cada .obj solo puede usar uno. Por supuesto, los archivos .pch pueden tener combinaciones arbitrarias de encabezados. Podrías tener un .pch para core + graphics, un .pch para core + physics, core + ai, etc. Esto funcionaría muy bien si ninguno de los archivos fuente necesitara 'hablar' más que core + one-module en un hora. Eso no me parece realista. Tal esquema y variantes en él suenan como una gran cantidad de trabajo de reestructuración sin ganancia real. No querrás construir montones de combinaciones y hacer un seguimiento de todas ellas. Es posible, pero no le ahorrará tiempo.

En mi opinión, está haciendo exactamente lo correcto sacrificando el tamaño del ejecutable para una rápida recuperación durante el desarrollo/depuración, y luego teniendo una forma más lenta pero más ligera de construir para la versión real.

Answer 2

En el pasado descubrí que rápidamente obtiene rendimientos decrecientes a medida que coloca más en los encabezados precompilados, por lo que si está tratando de agregar más para hacerlo más útil en una mayor cantidad de proyectos entonces golpeará un punto que se ralentiza. En nuestros proyectos, los archivos PCH toman más tiempo que la mayoría de los archivos fuente para compilarse, pero aún así solo unos pocos segundos como máximo. Sugeriría que los archivos PCH sean específicos para cada proyecto que esté utilizando. Tiene razón al decir que un archivo fuente solo puede referirse a un único archivo PCH, pero una forma de evitar esto es usar la opción 'forzar incluir' (en la pestaña Avanzado, creo) para asegurarse de que todos los archivos incluyen el PCH archivo para ese proyecto.