Prima assicurati di averne veramente bisogno: avere una libreria centrale che viene riutilizzata più di 100 volte funziona meglio quando l'interfaccia pubblica di quella libreria non cambia troppo spesso o solo in momenti specifici nel tempo. Controllare se è possibile suddividere la libreria in parti più piccole, in modo che le modifiche in una parte non influiscano sui progetti dipendenti delle altre parti. Controlla anche se è possibile sviluppare prima eventuali modifiche a quella libreria "in privato" e pubblicarle (visibilmente per la maggior parte dei progetti dipendenti) solo per le nuove "major release" di quella libreria.
Ma supponiamo che le dipendenze del progetto siano corrette e necessarie per il tuo sistema, e hai davvero bisogno di estendere le parti pubbliche di quella libreria centrale (o della classe centrale "A") molto spesso. Quindi, non è possibile evitare che tutti i progetti dipendenti debbano essere ricompilati. Ma poiché in genere non si apportano modifiche a tutti i 100 progetti contemporaneamente, non è necessario ricompilarli tutti sulla stazione di lavoro locale .
Ciò di cui hai bisogno in questa situazione è un < strong> build server - un server che controlla automaticamente tutte le modifiche dal tuo SCCS ed esegue una compilazione completa di tutti i 100 progetti in background. Per configurare un sistema di questo tipo, è necessario anche un buon processo di compilazione automatico . Spero che i tuoi 100 progetti possano essere suddivisi in gruppi di progetti che possono essere compilati e testati singolarmente, altrimenti devi prima risolvere il problema.
Anche una buona lettura, anche se un po 'obsoleta: Progetto software su larga scala in C ++ di John Lakos . Questo libro spiegherà anche l'idioma PIMPL citato da Jtrana in modo approfondito, anche se questo ti aiuterà solo con le parti private delle tue lezioni, non con quelle pubbliche come nel tuo esempio.