CMAKE_BUILD_TYPE wird nicht in CMakeLists.txt verwendet

Ich habe Probleme, meine Standard-Build-Konfiguration auf Release zu setzen, in meiner CMakeLists.txt-Datei setze ich CMAKE_BUILD_TYPE am Anfang der Datei mit

#enable Release ALWAYS, configure vars set(CMAKE_BUILD_TYPE Release) set(EXECUTABLE_NAME "ParticleSimulator") set(VERSION_MAJOR 0) set(VERSION_MINOR 2) 

Aber beim Erstellen meines Projekts und beim Öffnen der Lösung wird mir immer der Debug-Modus angezeigt, im Gegensatz zu dem, was ich in meiner CMakeLists-Datei angegeben habe. Was mache ich falsch? Ich habe mir einige der anderen Fragen angeschaut, aber ich habe nichts gesehen, was spezifisch für diese Frage war.

Ein corestück der CMakeLists.txt

Es gibt zwei Arten von Generatoren: Einzelkonfigurationen und Mehrfachkonfigurationen.

Einzelkonfigurationen

Make-like Generatoren: Unix Makefiles , NMake Makefiles , MinGW Makefiles , …

Sie legen den Konfigurationstyp im Schritt generieren fest:

 cmake -H. -B_builds/Debug -DCMAKE_BUILD_TYPE=Debug "-GUnix Makefiles" 

In diesem Fall ist Build-Schritt immer Debug:

 > cmake --build _builds/Debug /usr/bin/c++ -g ... > cmake --build _builds/Debug --config Debug # `--config` ignored /usr/bin/c++ -g ... > cmake --build _builds/Debug --config Release # yep, ignored /usr/bin/c++ -g ... 

Mehrfachkonfiguration

IDE-Generatoren: Visual Studio , Xcode

CMAKE_BUILD_TYPE bei Schritt generieren wird ignoriert, beides:

 > cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Debug "-GVisual Studio 12 2013 Win64" 

und

 > cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release "-GVisual Studio 12 2013 Win64" 

wird den gleichen Effekt haben:

Bildbeschreibung hier eingeben

Das liegt daran, dass alle Konfigurationen intern sind ( _builds/msvc-opaque/Release und _builds/msvc-opaque/Debug oder etwas, egal.) Sie können die Optionen --config zum --config :

 > cmake --build _builds --config Release cl /O2 ... > cmake --build _builds --config Debug cl /Od ... 

Steuerung (?)

Ja, du kannst. Definieren Sie einfach CMAKE_CONFIGURATION_TYPES :

 # Somewhere in CMakeLists.txt message("Generated with config types: ${CMAKE_CONFIGURATION_TYPES}") 

Standardausgabe:

 -- Detecting CXX compiler ABI info - done Generated with config types: Debug;Release;MinSizeRel;RelWithDebInfo -- Configuring done 

Schreibe es um:

 > cmake -H. -B_builds -DCMAKE_CONFIGURATION_TYPES="Debug;Release" "-GVisual Studio 12 2013 Win64" -- Detecting CXX compiler ABI info - done Generated with config types: Debug;Release -- Configuring done 

Bildbeschreibung hier eingeben

Sie können sogar Ihren eigenen Konfigurationstyp definieren:

 > cmake -H. -B_builds -DCMAKE_CONFIGURATION_TYPES="Debug;MyRelease" -DCMAKE_CXX_FLAGS_MYRELEASE="/My-Rel-flag" -DCMAKE_EXE_LINKER_FLAGS_MYRELEASE="/My-Linker-flags" "-GVisual Studio 12 2013 Win64" 

Bildbeschreibung hier eingeben

Und bauen:

cmake –build _builds –config MeineRelease

Unordentlich (?)

Überhaupt nicht, wenn Sie den Trick kennen 🙂 So bauen Sie config im Script / CI-Server / Dokumentations-Bauanleitung etc:

 > CONFIG=Debug > cmake -H. -B_builds "-DCMAKE_BUILD_TYPE=${CONFIG}" # Set Debug to Makefile, ignored by IDE > cmake --build _builds --config "${CONFIG}" # Build Debug in IDE, ignored by Makefile > (cd _builds && ctest -VV -C "${CONFIG}") # Test Debug in IDE, ignored by Makefile 

Schlechtes Muster

 if(CMAKE_BUILD_TYPE STREQUAL Debug) # Burn it with fire!!! set(CMAKE_BUILD_TYPE MySuperRelease) # Be ready to catch a bug from IDE user... 

Gute Eins

 set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} --my-debug-flags") 

functioniert gut.

 target_compile_definitions(MyTarget PUBLIC "$< $:MYDEBUG_MACRO>") 

Vielen Dank! 🙂 Sie sparen einen Tag für einen Programmierer.

functioniert für mich mit Makefile, ich bin glücklich …

Einige zitieren aus einem netten Buch von einem netten Kerl, den Sie wahrscheinlich kennen (Hervorhebung von mir):

Warum solltest du dich kümmern? Leute, die auf einer Vielzahl von Systemen programmieren oder eine Vielzahl von Compilern verwenden, kümmern sich sehr darum, wenn sie dies nicht tun, sind sie gezwungen, Zeit damit zu verschwenden , obskure Fehler zu finden und zu beheben. Leute, die behaupten, dass sie sich nicht um Portabilität kümmern, tun dies normalerweise, weil sie nur ein einziges System verwenden und das Gefühl haben, sie könnten sich die Einstellung leisten, dass die Sprache das ist, was mein Compiler implementiert. Das ist eine enge und kurzsichtige Sichtweise. Wenn Ihr Programm erfolgreich ist, wird es wahrscheinlich portiert, sodass jemand Probleme finden und beheben muss, die mit implementierungsabhängigen functionen zusammenhängen. Außerdem müssen Programme oft mit anderen Compilern für das gleiche System kompiliert werden, und selbst eine zukünftige Version Ihres Lieblingscompilers kann einige Dinge anders als die aktuelle machen. Es ist viel einfacher, die Auswirkungen von Implementierungsabhängigkeiten zu kennen und zu begrenzen, wenn ein Programm geschrieben wird, als zu versuchen, das Chaos danach zu entwirren.