Utilizzo di Makefile anziché di file di soluzione/progetto in Visual Studio (2005)

Question

Qualcuno ha esperienza nell'uso dei makefile per le build di Visual Studio C++ (in VS 2005) invece dell'utilizzo della configurazione progetto/soluzione.Per noi, il modo in cui funzionano il progetto/le soluzioni non è intuitivo e porta all'esplosione della configurazione quando si tenta di modificare le build con specifici flag di compilazione.

Sotto Unix, è abbastanza semplice impostare un makefile le cui opzioni predefinite siano sovrascritte dalle impostazioni dell'utente (o da altre impostazioni di configurazione).Ma fare questo tipo di cose sembra difficile in Visual Studio.

Ad esempio, abbiamo un progetto che deve essere creato per 3 piattaforme diverse.Ogni piattaforma potrebbe avere diverse configurazioni (ad esempio debug, rilascio e molte altre).Uno dei miei obiettivi su un progetto appena formato è quello di avere una soluzione che possa far sì che tutte le piattaforme siano costruite insieme, il che rende più semplice la creazione e il test delle modifiche al codice poiché non è necessario aprire 3 soluzioni diverse solo per testare il codice.Ma Visual Studio richiederà configurazioni 3 * (numero di configurazioni di base).cioè.Debug PC, debug X360, debug PS3, ecc.

Sembra che una soluzione makefile sia molto migliore qui.Avvolto con alcuni file batch o script di base, sarebbe facile mantenere al minimo l'esplosione della configurazione e mantenere solo un piccolo set di file per tutte le diverse build che dobbiamo eseguire.

Tuttavia, non ho esperienza con i makefile in Visual Studio e vorrei sapere se altri hanno esperienze o problemi da condividere.

Grazie.

(post modificato per menzionare che si tratta di build C++)

Answer 1

Ho riscontrato alcuni vantaggi nei makefile con progetti di grandi dimensioni, principalmente legati all'unificazione della posizione delle impostazioni del progetto.È in qualche modo più semplice gestire l'elenco dei file sorgente, includere percorsi, definizioni del preprocessore e così via, se sono tutti in un makefile o in un altro file di configurazione della build.Con più configurazioni, l'aggiunta di un percorso di inclusione significa che devi assicurarti di aggiornare manualmente ogni configurazione tramite le complesse proprietà del progetto di Visual Studio, il che può diventare piuttosto noioso man mano che un progetto cresce di dimensioni.

Anche i progetti che utilizzano molti strumenti di creazione personalizzati possono essere più facili da gestire, ad esempio se è necessario compilare pixel/vertex shader o codificare in altri linguaggi senza supporto VS nativo.

Avrai comunque bisogno di varie configurazioni di progetto diverse, poiché dovrai differenziare l'invocazione dello strumento di compilazione per ciascuna configurazione (ad es.passando diverse opzioni della riga di comando da creare).

Svantaggi immediati che mi vengono in mente:

• Build più lente:VS non è particolarmente veloce nel richiamare strumenti esterni o addirittura nel capire se è necessario creare un progetto in primo luogo.
• Dipendenze scomode tra progetti:È complicato configurarlo in modo che un dipendente faccia sì che il progetto di base venga creato, ed è ancora più complicato assicurarsi che vengano creati nell'ordine giusto.Ho avuto un certo successo nel convincere SCons a farlo, ma è sempre una sfida riuscire a lavorare bene.
• Perdita di alcune utili funzionalità IDE:Modifica e continua ad essere il principale!

In breve, dedicherai meno tempo alla gestione delle configurazioni del progetto, ma più tempo a convincere Visual Studio a funzionare correttamente con esso.

Answer 2

Visual Studio è stato costruito sopra MSBuild file di configurazione.È possibile considerare i file *proj e *sln come makefile.Ti consentono di personalizzare completamente il processo di creazione.

Answer 3

Sebbene sia tecnicamente possibile, non è una soluzione molto amichevole all'interno di Visual Studio.Ti combatterà per tutto il tempo.

Ti consiglio di dare un'occhiata NAnt.È un sistema di build molto robusto in cui puoi fare praticamente tutto ciò di cui hai bisogno.

Il nostro script NAnt esegue questa operazione su ogni build:

1. Migrare il database alla versione più recente
2. Genera entità C# dal database
3. Compila ogni progetto nella nostra soluzione "master".
4. Esegui tutti i test unitari
5. Esegui tutti i test di integrazione

Inoltre, il nostro server di build sfrutta questo aspetto e aggiunge un'altra attività, ovvero la generazione della documentazione Sandcastle.

Se non ti piace XML, potresti dare un'occhiata anche a Rastrello (rubino), Cuocere/BooBuildSystem (Boo), o Per favore (PowerShell)

Answer 4

Puoi utilizzare nant per creare i progetti individualmente sostituendo così la soluzione e avere 1 soluzione di codifica e nessuna soluzione di compilazione.

Una cosa da tenere a mente è che la soluzione e i file csproj dalla versione 2005 in poi sono script msbuild.Quindi, se acquisisci familiarità con msbuild, potresti essere in grado di maneggiare i file esistenti, per semplificare vs e per semplificare la distribuzione.

Answer 5

Abbiamo una configurazione simile a quella che descrivi.Supportiamo almeno 3 piattaforme diverse, quindi l'abbiamo scoperto utilizzando CMake per gestire le diverse soluzioni di Visual Studio.La configurazione può essere un po' faticosa, ma in pratica si riduce alla lettura dei documenti e a un paio di tutorial.Dovresti essere in grado di fare praticamente tutto ciò che puoi fare accedendo alle proprietà dei progetti e della soluzione.Non sono sicuro che sia possibile avere tutte e tre le piattaforme costruite insieme nella stessa soluzione, ma è possibile utilizzarle Regolazione automatica della velocità per prendersi cura delle tue build ed eseguire i tuoi script di test tutte le volte che è necessario.