2010-02-19 17 views
8

Sono impegnato nel porting del mio processo di compilazione da msbuild a cmake, per essere più in grado di gestire la toolchain gcc (che genera codice molto più veloce per alcune delle cose numeriche che sto facendo) .cmake: utilizzo di più configurazioni di output

Ora, mi piacerebbe cmake generare diverse versioni dell'output, cose come una versione con sse2, un'altra con x64 e così via. Tuttavia, cmake sembra funzionare in modo molto naturale se si dispone semplicemente di un gruppo di flag (ad esempio "sse2_enable" e "platform") e quindi generare un output basato su tali piattaforme.

Qual è il modo migliore per lavorare con più configurazioni di uscita come questa? Intuitivamente, mi piacerebbe scorrere su un gran numero di combinazioni di flag e rieseguire gli stessi file CMakeList.txt per ciascuna combinazione, ma ovviamente non è possibile esprimere quello all'interno dei file CMakeLists.txt (AFAIK) all'interno di.

risposta

4

Qui non c'è stata molta attività, quindi ho trovato una soluzione pratica. Probabilmente non è l'ideale, quindi se hai un'idea migliore, per favore aggiungila!

Ora, è difficile ripetere le configurazioni di compilazione in cmake perché le variabili cruciali di cmake non vivono nell'ambito della funzione, quindi, ad esempio, se si fa include_directories(X) la directory X rimarrà nell'elenco di inclusione anche dopo il la funzione termina.

Le directory hanno scope - e mentre normalmente ciascuna directory di input corrisponde a una directory di output, è possibile che sia con più directory di output.

Quindi, la mia soluzione si presenta come segue:

project(FooAllConfigs) 

set(FooVar 2) 
set(FooAnotherVar b) 
add_subdirectory("project_dir" "out-2b") 
set(FooVar 5) 
set(FooAnotherVar c) 
add_subdirectory("project_dir" "out-5c") 
set(FooVar 3) 
set(FooAnotherVar b) 
add_subdirectory("project_dir" "out-3b") 
set(FooVar 3) 
set(FooAnotherVar c) 
add_subdirectory("project_dir" "out-3c") 

Il normale dir progetto quindi contiene un file CMakeLists.txt con il codice per impostare l'appropriato include e le opzioni del compilatore date le variabili globali fissati nel progetto FooAllConfigs, e determina anche un suffisso di compilazione che viene aggiunto a tutti gli output di build: qualsiasi output incluso anche indirettamente (ad esempio come generato da add_executable) deve avere un nome univoco.

Questo funziona per me.

6

Il modo consigliato per farlo è semplicemente avere più directory di compilazione. Da ognuno si chiama semplicemente cmake con le impostazioni richieste.

Per esempio si potrebbe fare, a partire dalla directory di origine di base (utilizzando la sintassi shell Linux, ma l'idea è la stessa):

mkdir build-sse2 && cd build-sse2 
cmake .. -DENABLE_SSE2 # or whatever to enable it in your CMakeLists.txt 
make 

cd .. 

mkdir build-x64 && cd build-x64 
cmake .. -DENABLE_X64 # or whatever again... 
make 

In questo modo, ogni directory build è completamente separate l'una dall'altra.

Ciò consente di avere una directory per Debug, un'altra per Release e un'altra per cross-compiling.

+1

Tuttavia, ci sono diversi problemi con questo approccio. Prima di tutto, richiede più invocazioni per creare e guadagnare poco, ma introduce una complessità extra: cmake è * multipiattaforma *, ma lo scripting della shell non lo è. In secondo luogo, rallenta un po 'le cose; normalmente, puoi usare make -j per costruire tutte le varie combinazioni in modo piacevolmente multithread, ma con l'approccio di multiple-cmake devi parallelizzare manualmente (e accettare l'uso di mem più alto e caricare e rallentare perché le istanze separate di make non lo fanno cooperare). Il vantaggio è che può gestire conflitti di nomi. –

+0

Un altro svantaggio: un caso d'uso secondario che avevo in mente era più build per CPU diverse, e poi selezionando il migliore in fase di esecuzione - e poi c'è davvero bisogno che il risultato finale dipenda da più build dello stesso sub -progetto. –

+0

Comunque, è per questo che ho scelto l'altra soluzione - ma la tua è decisamente più canonica e funziona (con i suddetti inconvenienti) più in generale - grazie per aver contribuito! –

Problemi correlati