CMAKE_BUILD_TYPE은 CMakeLists.txt에서 사용되지 않습니다.
기본 빌드 구성을 릴리스로 설정하는 데 문제가 있습니다. 내 CMakeLists.txt 파일에서 파일 맨 위에 CMAKE_BUILD_TYPE을 다음과 같이 설정합니다.
#enable Release ALWAYS, configure vars
set(CMAKE_BUILD_TYPE Release)
set(EXECUTABLE_NAME "ParticleSimulator")
set(VERSION_MAJOR 0)
set(VERSION_MINOR 2)
하지만 내 프로젝트를 빌드하고 솔루션을 열면 CMakeLists 파일에 지정한 것과는 달리 항상 디버그 모드가 표시됩니다. 내가 도대체 뭘 잘못하고있는 겁니까?
나는 거기에서 다른 질문 중 일부를 살펴 보았지만이 질문에 특정한 것을 보지 못했습니다.
CMakeLists.txt 의 요점 .
생성기에는 단일 구성과 다중 구성의 두 가지 유형이 있습니다.
단일 구성
Make-like 생성기 : Unix Makefiles , NMake Makefiles , MinGW Makefiles , ...
생성 단계에서 구성 유형을 설정합니다.
cmake -H. -B_builds/Debug -DCMAKE_BUILD_TYPE=Debug "-GUnix Makefiles"
이 경우 빌드 단계는 항상 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 ...
다중 구성
IDE 생성기 : Visual Studio , Xcode
CMAKE_BUILD_TYPE
생성 단계에서 무시됩니다.
> cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Debug "-GVisual Studio 12 2013 Win64"
과
> cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release "-GVisual Studio 12 2013 Win64"
동일한 효과가 있습니다.
모든 구성은 내부에 있기 때문에 (즉, 인 _builds/msvc-opaque/Release
및 _builds/msvc-opaque/Debug
또는 뭔가 문제가되지 않습니다). --config
옵션을 사용 하여 다음을 전환 할 수 있습니다 .
> cmake --build _builds --config Release
cl /O2 ...
> cmake --build _builds --config Debug
cl /Od ...
제어 (?)
그래 넌 할수있어. CMAKE_CONFIGURATION_TYPES를 정의 하십시오 .
# Somewhere in CMakeLists.txt
message("Generated with config types: ${CMAKE_CONFIGURATION_TYPES}")
기본 출력 :
-- Detecting CXX compiler ABI info - done
Generated with config types: Debug;Release;MinSizeRel;RelWithDebInfo
-- Configuring done
다시 작성하십시오.
> 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
자체 구성 유형을 정의 할 수도 있습니다.
> 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"
그리고 빌드 :
cmake --build _builds --config MyRelease
지저분한 (?)
트릭을 안다면 전혀 아닙니다 :) 스크립트 / CI 서버 / 문서의 빌드 지침 등에서 구성을 빌드 / 테스트하는 방법입니다.
> 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
잘못된 패턴
if(CMAKE_BUILD_TYPE STREQUAL Debug) # Burn it with fire!!!
set(CMAKE_BUILD_TYPE MySuperRelease) # Be ready to catch a bug from IDE user...
Good one
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} --my-debug-flags")
Works nice.
target_compile_definitions(MyTarget PUBLIC "$<$<CONFIG:Debug>:MYDEBUG_MACRO>")
Thank you! :) You save a day for one programmer.
Works for me with Makefile, I'm happy ...
Some quote from a nice book of a nice guy you probably know (emphasis mine):
Why should you bother? People who program on a variety of systems or use a variety of compilers care a lot because if they don’t, they are forced to waste time finding and fixing obscure bugs. People who claim they don’t care about portability usually do so because they use only a single system and feel they can afford the attitude that ‘‘the language is what my compiler implements.’’ This is a narrow and shortsighted view. If your program is a success, it is likely to be ported, so someone will have to find and fix problems related to implementation dependent features. In addition, programs often need to be compiled with other compilers for the same system, and even a future release of your favorite compiler may do some things differently from the current one. It is far easier to know and limit the impact of implementation dependencies when a program is written than to try to untangle the mess afterwards.
One possibility that occurs is that one of the sub-modules had set the CMAKE_BUILD_TYPE
value in the cache, that is:
SET(CMAKE_BUILD_TYPE Debug CACHE)
Meaning that that value will be updated permanently from that point to the end of the configuration run.
One great way to track the offending place where this value has changed is by using CMake's variable_watch. In your main CMakelists.txt
file, add the following line
variable_watch(CMAKE_BUILD_TYPE)
This will print to the standard error every access to this variable. And to get it to log file, do something like:
cmake <your options> 2>variable_watch.log
You may see something like:
CMake Debug Log at <...>/CMakeLists.txt:184 (add_library): Variable "CMAKE_BUILD_TYPE" was accessed using READ_ACCESS with value "Debug".
Then you will likely see the point(s) where CMAKE_BUILD_TYPE was first changed. And from here you'll be much closer to trace the offending CMake line.
ReferenceURL : https://stackoverflow.com/questions/24460486/cmake-build-type-is-not-being-used-in-cmakelists-txt
'IT TIP' 카테고리의 다른 글
선택기“.class.class”와“.class .class”의 차이점은 무엇입니까? (0) | 2021.01.09 |
---|---|
Bootstrap 3-화면 크기에 따라 모달 창의 높이 설정 (0) | 2021.01.09 |
Laravel 5 Resourceful Routes Plus 미들웨어 (0) | 2021.01.09 |
맥북 adb는 인터페이스를 열 수 없습니다 (0) | 2021.01.09 |
'관찰 가능'유형에 '필터'속성이 없습니다. (0) | 2021.01.09 |