La soluzione add_custom_target(run ALL ...
funzionerà per i casi più semplici quando si ha un solo bersaglio sei costruire, ma si rompe quando hai più obiettivi di primo livello, ad es app e test.
Mi sono imbattuto in questo stesso problema quando stavo cercando di impacchettare alcuni file di dati di test in un file oggetto in modo che i miei test di unità non dipendessero da nulla di esterno. Ho risolto il problema utilizzando add_custom_command
e alcune magie di dipendenza aggiuntive con set_property
.
add_custom_command(
OUTPUT testData.cpp
COMMAND reswrap
ARGS testData.src > testData.cpp
DEPENDS testData.src
)
set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
add_executable(app main.cpp)
add_executable(tests unit-tests.cpp)
Così ora testData.cpp sarà generato prima unità-tests.cpp viene compilato, e ogni volta testData.src modifiche. Se il comando che stai chiamando è molto lento ottieni il bonus aggiuntivo che quando costruisci solo l'obiettivo dell'app non dovrai aspettare per quel comando (di cui solo l'eseguibile di test ha bisogno) per terminare.
Non è mostrato sopra, ma un'applicazione accurata di ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories()
manterrà pulito l'albero dei sorgenti dei file generati.
fonte
2011-07-22 04:07:40
add_custom_target [potrebbe] (http://stackoverflow.com/a/15973676/704244) essere un'alternativa a add_custom_command –