IT TIP

CMAKE_BUILD_TYPE은 CMakeLists.txt에서 사용되지 않습니다.

itqueen 2021. 1. 9. 11:13
반응형

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

반응형