2011-10-19 12 views
9

Sto cercando di utilizzare cmake (su Linux con GNU make e g ++) per creare un progetto con due sottodirectory: MyLib e MyApp. MyLib contiene l'origine per una libreria statica; MyApp deve collegarsi a quella libreria. Sto cercando di costruire su Linux con makefiles generati utilizzando il seguente CMakeLists.txt:CMAKE: Costruisci libreria e link contro di esso

cmake_minimum_required (VERSION 2.6) 
project (MyProj) 
include_directories (MyLib) 
file(GLOB MyLibSrc MyLib/*.cpp) 
add_library(MyLibrary STATIC ${MyLibSrc}) 
file(GLOB MyAppSrc MyApp/*.cpp) 
add_executable(MyApplication ${MyAppSrc}) 
target_link_libraries(MyApplication MyLibrary) 

Questo 'quasi' opere. Fallisce al momento del collegamento perché mentre genera libMyLibrary.a - è nella radice. Quando aggiungo:

link_directories(${MyProj_BINARY_DIR}) 

non fa differenza.

ho un paio di domande (inter-connessi):

  1. Qual è il modo migliore per costringere CMake nella costruzione di mia biblioteca e eseguibile in una 'directory di gestione temporanea' — dicono MyStage — per mantenere obiettivi separati dalla fonte?
  2. Come convinto cmake a collegare l'applicazione alla libreria?
  3. Se volevo creare una versione di debug e una versione di rilascio, qual è il modo migliore per estendere i miei script cmake per fare questo — assicurandoti che i collegamenti dell'applicazione di debug contro la libreria di debug e l'applicazione di rilascio contro la libreria di rilascio?

Sono un nuovo arrivato relativo a cmake. Ho letto quello che riesco a trovare sul Web, ma mi trovo a dover lottare per ottenere il collegamento tra la mia libreria e il mio eseguibile. Questo tipo di configurazione, secondo me, dovrebbe essere abbastanza comune. Un esempio da cui dare una greppia sarebbe molto utile, ma non l'ho trovato.

risposta

3
  1. Utilizzare "fuori dalla compilazione di origine". Creare una directory usata solo per costruire e, mentre in esso, chiamare

    cmake <path to the sources, it may be relative>
  2. O utilizzare

    link_directories(${MyProj_BINARY_DIR}/MyLib)

    o fare CMakeLists.txt in ogni sottodirectory - che sarebbe meglio per il progetto più grande di molto piccolo.

  3. Questo è un po 'complicato, controlla CMAKE_BUILD_TYPE nei documenti (puoi impostarlo e/o "se" da esso). È inoltre possibile impostare dalla riga di comando:

    cmake -DCMAKE_BUILD_TYPE=Debug
+0

posso vedere come (1) potrebbe lavorare - anche se non credo che sia pulito. Non voglio CMakeLists.txt nella mia 'directory di staging' insieme alla mia libreria, se posso aiutarlo. – aSteve

+0

Uhm, no, no, CMakeLists.txt rimangono nell'albero dei sorgenti. Il percorso passato come argomento per cmake è la directory che contiene il CMakeLists.txt di livello superiore. In questa configurazione, la directory "staging" è completamente vuota prima della chiamata cmake. – kralyk

3

ho scoperto la soluzione 'ottimale' per (1) ... quindi, pensato di postare qui:

SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY MyStage) 
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY MyStage) 

La cosa che mi ha confuso in precedenza è che le librerie statiche non sono considerate una LIBRERIA di Cmake - sono considerate ARCHIVE.

+0

L'unica risposta utile che ho trovato! La denominazione è così confusa! – rationalcoder

15

Bene, è meglio leggere example e fare ciò che è esattamente suggerito.

cmake_minimum_required (VERSION 2.6) 
project (MyProj CXX) 
add_subdirectory(MyLib) 
add_subdirectory(MyApp) 

Quindi per ogni sottodirectory specificata, CMakeLists.file txt vengono creati

MyLib \ CMakeLists.txt

file(GLOB SRC_FILES *.cpp) 
add_library(MyLib ${SRC_FILES}) 

MyApp \ CMakeLists.txt

file(GLOB SRC_FILES *.cpp) 
add_executable(MyApp ${SRC_FILES}) 
target_link_libraries(MyApp MyLib) 
Problemi correlati