La nostra azienda sviluppa e vende una libreria C ++ multipiattaforma. Distribuiamo versioni solo binari per Windows, Mac OS X, Linux, iOS, Android, ecc. L'unico codice sorgente che i clienti ricevono sono i file di intestazione con le interfacce di classe. Il nostro IDE è Visual Studio; siamo molto contenti ora supporta la compilazione incrociata immediata (controllo remoto clang! di un Mac con XCode! Possibilità di richiamare versioni precedenti del compilatore! Rende le nostre vite molto più semplici). Proviamo a costruire tutte le versioni contemporaneamente sullo stesso computer di costruzione (che chiama un Mac per fare le porte iOS e Mac OS X). La maggior parte dei clienti è su Windows e ottiene solo le librerie per Visual C ++ recente, ma alcuni clienti ottengono il lavoro.
Il codice stesso è lo stesso tra le piattaforme.
Tuttavia, non tutti i nostri clienti sono sull'ultima versione di Visual Studio - alcuni di loro utilizzano versioni già nel 2005. Mentre stiamo cercando di incoraggiarli a passare a una versione più recente, dobbiamo ancora supporta i vecchi se trovano un bug.
Questo porta a una proliferazione di configurazioni del prodotto: (Debug / Release) * (Libreria statica / Libreria condivisa) * (Piattaforma) * (x86 / x64 / ARM) * (Versione del compilatore)
molti dei quali sono molto simili tra loro, ma con alcune differenze.
Stavo studiando MSBuild e giocavo con il file .vcxproj , ma sembra ancora estremamente complicato (e Visual Studio si strozza su qualsiasi .vcxproj con qualcosa di più di un minimo di modifiche).
Il modo in cui eravamo abituati a gestire questo era di modificare manualmente il progetto ogni volta che stavamo facendo una nuova build. Ovviamente è insostenibile.
Mi è stato assegnato il compito di aggiornare il progetto e inizialmente ho creato una serie di nuove configurazioni, corrispondenti a quell'assurdo prodotto incrociato che ho menzionato sopra. Penso che faccia per 40 configurazioni. Ugh. Ma a parte il mal di testa della gestione, non ho sempre apportato le modifiche necessarie alle impostazioni del progetto quando copiavo da (xx) x86 a x64. Quindi alcune delle nuove configurazioni non sono state create quando ho creato un batch.
Per evitare che ciò accada di nuovo, ho creato un sacco di nuovi macro utente nel file di progetto (probabilmente avrebbe dovuto essere nel file .props di riferimento in
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release-2013|Win32'"
Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props"
Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')"
Label="LocalAppDataPlatform" />
<Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC60.props" />
</ImportGroup>
Suppongo) e mi sono assicurato che tutte le configurazioni del progetto fossero uguali e che le modifiche tra ognuna di esse fossero state fatte nelle macro dell'utente. Ma anche questo diventa ingombrante, e tirando giù un menu di 40 cose per selezionare la cosa giusta da costruire, oltre a dover andare nella giusta cartella e scegliere i file rilevanti, sembra anche soggetto a errori.
Quindi la mia domanda è: come posso renderlo più automatico e non richiedere così tanto pensiero? Le persone che creano una libreria multipiattaforma funzionano davvero con oltre 40 configurazioni nel loro progetto? In che modo le persone riescono a gestirlo nella vita reale - o almeno impostano le cose in modo che non commettano così tanti errori?