CMAKE_BUILD_TYPE wird in CMakeLists.txt nicht verwendet
Ich habe Probleme beim Festlegen meiner Standarderstellungskonfiguration auf Release. In meiner Datei CMakeLists.txt 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)
beim Erstellen meines Projekts und dem Öffnen der Lösung wird jedoch, anders als in meiner CMakeLists-Datei angegeben, immer der Debug-Modus angezeigt. Was mache ich falsch? Ich habe mir einige der anderen Fragen dort angesehen, aber nichts konkretes für diese Frage gefunden.
Eine Übersicht der CMakeLists.txt
Es gibt zwei Arten von Generatoren: Einzelkonfigurationen und Mehrfachkonfigurationen.
Einzelne Konfigurationen
Make-like-Generatoren: Unix-Makefiles , NMake-Makefiles , MinGW-Makefiles , ...
Den Konfigurationstyp legen Sie im Generierungsschritt fest:
cmake -H. -B_builds/Debug -DCMAKE_BUILD_TYPE=Debug "-GUnix Makefiles"
In diesem Fall lautet der Erstellungsschritt 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 ...
Multi-Konfiguration
IDE-Generatoren: Visual Studio , Xcode
CMAKE_BUILD_TYPE beim Generieren wird ignoriert, beide:
> 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:
Dies liegt daran, dass alle Konfigurationen intern sind (d. H. _builds/msvc-opaque/Release und _builds/msvc-opaque/Debug oder so, egal). Sie können --config Optionen zum Umschalten:
> 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
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"
Und bauen:
cmake --build _builds --config MyRelease
Chaotisch (?)
Überhaupt nicht, wenn Sie den Trick kennen :) So erstellen/testen Sie die Konfiguration in einer Skript-/CI-Server-/Dokumentations-Build-Anleitung usw .:
> 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...
Gut
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} --my-debug-flags")
Funktioniert gut.
target_compile_definitions(MyTarget PUBLIC "$<$<CONFIG:Debug>:MYDEBUG_MACRO>")
Danke! :) Sie sparen einen Tag für einen Programmierer.
Funktioniert für mich mit Makefile, ich bin glücklich ...
Einige Zitate aus einem Netten Buch eines Netten Mannes , den Sie wahrscheinlich kennen (Hervorhebung meines):
Warum sollten Sie sich die Mühe machen? Menschen, die auf einer Vielzahl von Systemen programmieren oder eine Vielzahl von Compilern verwenden, kümmern sich sehr darum, denn wenn sie dies nicht tun, sind sie gezwungen, Zeit zu verschwenden und zu finden Beheben von obskuren Fehlern. Menschen, 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, sich die Haltung leisten zu können, die die Sprache vertritt implementiert mein Compiler. '' Dies ist ein enger und kurzsichtiger Aussicht. Wenn Ihr Programm erfolgreich ist, wird es wahrscheinlich portiert, sodass jemand Probleme im Zusammenhang mit implementierungsabhängigen Funktionen finden und beheben muss. Darüber hinaus müssen Programme häufig mit anderen Compilern für dasselbe System kompiliert werden, und selbst eine zukünftige Version Ihres bevorzugten Compilers kann einige Dinge anders als die aktuelle ausführen. Es ist viel einfacher, die Auswirkungen von Implementierungsabhängigkeiten beim Schreiben eines Programms zu kennen und einzuschränken, als zu versuchen, das Chaos danach zu entwirren.
Eine Möglichkeit, die auftritt, ist, dass eines der Submodule den CMAKE_BUILD_TYPE-Wert im Cache festgelegt hat, I.E:
SET(CMAKE_BUILD_TYPE Debug CACHE)
dies bedeutet, dass dieser Wert dauerhaft von diesem Punkt bis zum Ende des Konfigurationslaufs aktualisiert wird. Eine gute Möglichkeit, den fehlerhaften Ort zu verfolgen, an dem sich dieser Wert geändert hat, ist die Verwendung von cmake's variable_watch . Fügen Sie in Ihrer CMakelists.txt-Hauptdatei die folgende Zeile hinzu
variable_watch(CMAKE_BUILD_TYPE)
Bei jedem Zugriff auf diese Variable wird der Standardfehler ausgegeben. Und um es zur Protokolldatei zu bringen, machen Sie etwas wie:
cmake <your options> 2>variable_watch.log
Sie können etwas sehen wie:
CMake Debug Log unter <...>/CMakeLists.txt: 184 (add_library): Auf die Variable "CMAKE_BUILD_TYPE" wurde mit READ_ACCESS mit dem Wert .__ zugegriffen. "Debuggen".
Dann werden Sie wahrscheinlich die Punkte sehen, an denen CMAKE_BUILD_TYPE zuerst geändert wurde. und von hier aus sind Sie der anstößigen cmake-Linie viel näher.