2010-11-08 17 views
9

Ho un framework che viene utilizzato da diversi progetti (che include diversi esempi per mostrare come funziona il framework). Il framework ha componenti come core, grafica, fisica, gui ecc. Ognuno è una libreria separata. Ci sono anche diverse configurazioni.Condivisione efficiente delle intestazioni precompilate

Un file di soluzione principale compila il progetto completo con tutte le possibili configurazioni in modo che i progetti possano utilizzare le librerie. Poiché il framework viene raramente ricompilato, soprattutto da qualcuno (incluso me) che lavora su un progetto che utilizza il framework, ha senso precompilare le molte intestazioni.

Inizialmente, ogni progetto/campione aveva la propria intestazione precompilata utilizzata per l'intero progetto. Ogni volta che dovrei ricostruire lo stesso pch (ad esempio, Debug), così ho deciso che un PCH condiviso ridurrebbe la compilazione ridondante di PCH. Fin qui tutto bene. Ho un progetto che compila il PCH insieme alle librerie. Tutti i progetti/campioni successivi ora utilizzano lo stesso PCH. Questo ha funzionato meravigliosamente.

L'unico problema è che ho visto un aumento delle dimensioni del file. Questo non è un ostacolo, come se un progetto che usa il framework sia destinato a essere rilasciato, può separarsi dal PCH condiviso e crearne uno proprio. Ho fatto questo per il rapido sviluppo (ho effettivamente creato uno strumento che crea i file di progetto VS e i file sorgente per un nuovo progetto/campione pronto per essere costruito e per facilitare l'aggiornamento di un progetto precedente che utilizzava un vecchio versione del framework).

In ogni caso, (presumo che) l'aumento delle dimensioni del file è dovuto al fatto che il file di progetto VS indipendente che sta creando il PCH condiviso include tutte le intestazioni di tutte le librerie. La mia domanda è se posso utilizzare la compilazione condizionale (#ifndef) per ridurre la dimensione dell'eseguibile finale? O magari condividere più file PCH in qualche modo (per quanto ne so, però, non è possibile, ma forse sbaglio) Se non ho senso, per favore dillo (in parole gentili :)) dato che la mia conoscenza dei file PCH è molto limitata .

Grazie!

Nota: per riattivare e chiarire, finora, ho un file di soluzione che sta compilando tutte le librerie incluso il PCH condiviso. Ora, se ricompongo tutti gli esempi e i progetti, si compila in un paio di secondi o più al massimo. Prima, ogni progetto ricreava un file PCH. Inoltre, inizialmente volevo un PCH per ogni libreria, ma poi ho scoperto che un file sorgente non può usare più file PCH, quindi questa opzione non era fattibile. Un'altra opzione è quella di compilare tutte le possibili combinazioni di file PCH, ma è troppo dispendioso in termini di tempo e ingombro e soggetto a errori.

+2

PER FAVORE VOTARE QUESTO: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4931119-allow-precompiled-headers-to-be-shared-between-pro –

risposta

1

Sembra che il problema delle dimensioni derivi dall'utilizzo di intestazioni che non sono effettivamente necessarie, ma che è ancora logico utilizzare queste intestazioni quando si sviluppano a causa della rotazione più rapida.

Su utilizzando #ifndefs: La precompilazione è scadente. Si perde la capacità di condividere il lavoro di precompilazione nel punto in cui c'è una differenza. Se si usa #ifndefs per fare diverse varianti di ciò che si include, io. se avete

#ifndef FOO 

Poi l'intestazione precompilata deve fermare prima del punto in cui FOO è definito in modo diverso in due file che utilizzano tale intestazione precompilata. Quindi #ifndef non risolverà il problema. Il risultato netto è che FOO deve essere lo stesso, o sei di nuovo per separare i file pch per i diversi progetti. Né risolve le cose.

Per quanto riguarda condivisione di più file .pch: Un limite fondamentale di file .pch è che ogni .obj può utilizzarne solo uno. Naturalmente i file .pch possono avere combinazioni arbitrarie di intestazioni. Potresti avere una .pch per la grafica core +, una .pch per core + physics, core + ai ecc. Funzionerebbe semplicemente dandy se nessuno dei file sorgente fosse necessario per "parlare" a più di core + un modulo in un tempo. Non mi sembra realistico. Un simile schema e varianti suona come un sacco di lavori di ristrutturazione senza alcun guadagno reale. Non vuoi creare miliardi di combinazioni e tenerne traccia. È possibile, ma non ti farà risparmiare tempo.

Dal mio punto di vista si sta facendo esattamente la cosa giusta sacrificando la dimensione dell'eseguibile per un rapido turn-around durante lo sviluppo/debug, e quindi avendo un modo più lento ma più snello di costruire per la versione attuale.

0

In passato ho scoperto che si eseguono abbastanza rapidamente rendimenti decrescenti mentre si inseriscono di più nelle intestazioni precompilate, quindi se si sta tentando di inserirle di più per renderlo più utile in un numero maggiore di progetti poi colpirà un punto che rallenta. Sui nostri progetti i file PCH impiegano più tempo della maggior parte dei file sorgenti per essere compilati, ma ancora solo per pochi secondi al massimo. Suggerirei di rendere i file PCH specifici per ogni progetto che si sta utilizzando. Hai ragione nel dire che un file sorgente può riferirsi solo a un singolo file PCH, ma un modo per aggirare questo è usare l'opzione 'force include' (nella scheda Avanzate credo) per assicurare che tutti i file includano il PCH file per quel progetto.

Problemi correlati