[CMake] An Introduction to Modern CMake 정리

💡 본 문서는 'An Introduction to Modern CMake'에 대해 정리해놓은 글입니다.
CMake를 사용하는 이유부터 CMake의 구성 및 CMakeLists.txt 파일 작성법까지 다루고 있으니 CMake를 입문하여 활용하는 입장에서 많은 도움이 될 것입니다.

1. CMake 란

1.1 CMake 도입

CMake는 Kitware에서 개발하고 있으며, cmake.org에서 학습하고 다운로드 할 수 있습니다.

전통적인 C/C++ 빌드 도구는 make입니다. make는 Makefile을 작성해 주어야 하는데, Makefile 작성시 의존관계를 개발자가 직접 기술해야 하며, 개발자는 정확한 의존성을 위해 소스코드를 들여다보며 많은 노동을 투입하여 작성해야 합니다.

Makefile 작성시 실수로 의존관계를 빠뜨리면 변경이 업데이트 되지 않거나, 컴파일 오류나 런타임 오류가 발생하기도 합니다. 특히 런타임 오류는 그 원인을 파악하기도 어렵습니다. make 사용시 clean 구성을 자주 사용하기도 하는 이유기도 합니다.

CMake는 소스파일을 파싱하여 의존관계를 파악하여 자동으로 Makefile들이 작성되도록 돕는 것이 1차 목표 입니다.

1.2 CMake 단계

CMake를 사용하는 것은 cmake에 의해 CMakeLists.txt를 파싱하거나 Makefile들을 생성하는 구성(Configure) 단계와, make에 의한 빌드 (Build) 단계 + 설치(install) 단계로 나눠 볼 수 있습니다.

Configure 단계: CMakeLists.txt를 파싱하고 실행하여 Makefile 이나 Ninja, vsproj등을 생성하는 단계이며, 이 파일들을 자동으로 구성하는 것이 cmake의 기본 목표 입니다. 이 글은 Makefile만을 구성하는 과정을 다룹니다.

cmake ..: CMakeLists.txt -> Cmake를 이용하여 Makefile 생성

build 단계: 다른 외부 도구를 사용합니다. Makefile을 생성하였으면 make를 실행 합니다.

make: Makefile을 이용하여 실행 파일 생성.

install 단계:

sudo make install:

+ 빌드 옵션 (CMAKE_BUILD_TYPE)

다양한 모드의 빌드옵션으로 실행할 수 있습니다. 선택한 빌드옵션에 따라 컴파일 및 링크 옵션이 추가 됩니다.

Debug(`-O0 -g`): 디버깅을 위한 빌드.
- No optimization, asserts enabled, [custom debug (output) code enabled], debug info included in executable (so you can step through the code with a debugger and have address to source-file:line-number translation).
Release(`-O3 -DNDEBUG`): 배포를 위한 빌드.
- high optimization level, no debug info, code or asserts.
RelWithDebInfo(`-O2 -g -DNDEBUG`): 배포를 위한 빌드이지만 디버깅 정보 포함.
- optimized, *with* debug info, but no debug (output) code or asserts.
MinSizeRel(`-Os -DNDEBUG`): 배포를 위한 빌드인데 최소 크기로 최적화.
- same as Release but optimizing for size rather than speed.

2. CMake 실행하기: CMakeLists.txt

2.1 CMake 실행하기: Make 빌드 시스템 이용

CMake 를 사용하는 모든 프로젝트에는 반드시 프로젝트 최상위 디렉토리에 *CMake 파일이 있어야 합니다. 여기서 CMake 파일은 대부분 'CMakeLists.txt' 라는 이름으로 작성하며, 빌드 파일을 생성하는데 필요한 정보들이 들어 있습니다.

컴파일 과정: CMakeLists.txt -> Cmake를 이용하여 Makefile 생성 -> Makefile을 이용하여 실행 파일 생성.

// 프로젝트의 최상단 CMakeLists.txt 
$ mkdir build; cd build
$ cmake ..
$ make

주의!!!: 반드시 빌드 파일 용 디렉토리(/build)를 만든 다음에 해당 디렉토리에서 CMake 를 실행합시다.
CMake 는 실행시 여러가지 파일들 (캐시 용도로) 을 생성하는데 이 때문에 프로젝트 디렉토리가 난장판이 될 수 있습니다.

2.1.1 CMakeList.txt 변경 후 재빌드: rm build/CMakeCache.txt

// pwd: 프로젝트의 최상단의 CMakeLists.txt파일이 있는 곳
$ cd build
$ rm CMakeCache.txt

CMakeCache.txt만 지워져도 cmake .. 시 재빌드됨.

2.1.2 CMakeList.txt 이외의 파일 변경 후 재빌드: make clean

// pwd: 프로젝트의 최상단의 CMakeLists.txt파일이 있는 곳
$ cd build
$ make clean

makefile내에 clean 옵션으로 clean시 삭제될 파일을 명시합니다.

all: $(BUILD) 
clean: ; rm -f *.o $(BUILD)

2.2 CMake: Make 이외의 빌드 시스템 이용

CMake 에서 따로 설정하지 않았다면 디폴트로 make 가 선택되지만 경우에 따라 빌드 시스템에 맞는 다른 빌드 프로그램(sln, vcxproj, MakeFiles, ninja ...)을 선택해야 합니다.

$ cmake .. -DCMAKE_GENERATOR=Ninja

위 CMAKE_GENERATOR 인자로 원하는 빌드 시스템을 호출하도록 전달하면 되는데, 전체 목록은 여기 에서 보실 수 있습니다.

대표적으로...

"Unix Makefiles" (디폴트)
"Ninja"
"Visual Studio 16 2019"

+ 빌드 시스템/툴체인 지정

툴체인 파일: CMake가 지원하는 다양한 기능들을 사용해 빌드를 수행할 수 있도록 미리 지정된 파일을 의미합니다.

cmake --build . # ... 지정된 툴을 사용해 빌드를 진행한다 ...
cmake --build . --parallel          # 병렬 빌드
cmake --build . --target install    # 빌드에 성공하면 설치까지 진행한다
cmake --build . --config debug      # Debug로 빌드

Android NDK에서는 여러 아키텍처로의 크로스 컴파일에 필요한 설정들이 작성된 android.toolchain.cmake 파일이 함께 제공되며, CMake를 사용한 빌드를 수행시에 Gradle에 의해서 자동으로 지정합니다.
iphone을 대상으로 하는 경우에는 https://github.com/leetal/ios-cmake 를 사용해 XCode 프로젝트를 생성하기도 합니다.
다르게는 https://github.com/Microsoft/vcpkg 와 같이 라이브러리 탐색에 특화된 툴체인 파일을 사용하는 경우도 있습니다.

# ... Vcpkg에서 제공하는 cmake 툴체인의 경로로 제공한다 ...
cmake ../ -G "Visual Studio 15 2017 Win64" -DCMAKE_TOOLCHAIN_FILE="X:\Develop\vcpkg\scripts\buildsystems\vcpkg.cmake"

3. CMake 기초 문법 정리

3.1 필수적인 CMake: 최상단 CMakeLists.txt 파일

최소 버전 명기

모든 CMake 파일의 최상단에는 최소 버전이 명시되어야 합니다. 다음과 같습니다.

cmake_minimum_required(VERSION 3.10)

프로젝트 설정

최상위 CMake 파일은 다음 내용을 포함해야 합니다.

project(MyProject VERSION 1.0
                  DESCRIPTION "Very nice project"
                  LANGUAGES CXX)

스트링은 ““ 처리
공백문자는 의미를 가지지 않음
LANGUAGES 는 C CXX가 default이며, 그 외에도 CUDA, OBJC, OBJCXX, Fortran 등등이 가능합니다.

설정 파일

configure_file(TutorialConfig.h.in TutorialConfig.h)

configure file을 추가했다면 반드시 include 경로를 추가해주어야 합니다.

target_include_directories(${PROJECT_NAME}
  PUBLIC
    ${PROJECT_BINARY_DIR}/include
)

configure_file에 대한 세부적인 내용은 [CMake] configure_file(): CMake 변수값을 파일에 반영!을 참고하도록 합시다.

빌드 관계 설정 (의존성)

프로젝트 내에서 여러 라이브러리를 빌드한다면, 그리고 서로 의존성이 있다면 이를 제어하는 것도 가능합니다. 이 과정은 보통 해당 sub-project들을 모두 확인할 수 있는 CMakeList에서 수행하게 됩니다.

아래와 같은 형태로 프로젝트가 구성되었다고 가정하겠습니다.

$ tree ./multiple-library-project
./multiple-library-project
├── CMakeLists.txt      # <--- Root CMakeList
├── include
│   └── ... 
├── module1
│   ├── CMakeLists.txt
│   └── ... 
├── module2
│   ├── CMakeLists.txt
│   └── ... 
└── test
    ├── CMakeLists.txt
    └── ...

상단의 CMakeLists.txt 파일에서 하위 폴더(module1, module2, test)를 추가해야 합니다.

# multiple-library-project/CMakeLists.txt
add_subdirectory(module1)
add_subdirectory(module2)
add_subdirectory(test)

module2가 module1의 기능을 사용하고, test는 이 둘의 기능을 모두 사용한다면 이는 Root CMake에서 다음과 같이 명시할 수 있습니다.

# dependency: from -> { to }
add_dependencies(module1 module2)            # `module1` requires `module2`
add_dependencies(test    module1 module2)    # `test` requires `module1` & `module2`

이를 바탕으로 CMake에서 프로젝트가 생성되면, 그 프로젝트는 의존성을 고려하여 module1, module2, test 순서로 빌드를 진행하게 됩니다.

3.2 타겟(target) & 속성(property)

target이란? 프로그램을 구성하는 요소들(실행파일, 라이브러리 등)
property란? 각 타겟에 대한 속성(컴파일 옵션, 링킹할 라이브러리, include할 파일의 위치 등)
- 모든 CMake 명령은 그냥 타겟을 정의하고 (add_executable), 해당 타겟들의 속성을 지정하는 명령들 (target_compile_options) 로 이루어집니다.

타겟(Target): 실행 파일 생성

add_executable(one two.cpp three.h)

이후에 나오는 .cpp 파일을 사용해 실행파일을 생성합니다.
실행파일명, 소스명 순으로 기재합니다.
소스는 복수 개를 기재할 수 있습니다.
헤더는 무시되지만, 특정 IDE는 헤더가 명시되어 있어야 인식할 수 있으므로 필요에 따라 기재합니다.

타겟(Target): 라이브러리 생성

add_library(one STATIC two.cpp three.h)

add_executable과 같이 맨 처음에는 라이브러리명을 기재하며, 이후에 나오는 .cpp 파일을 사용해 라이브러리를 생성합니다.
라이브러리는 STATIC, SHARED, MODULE을 통해 선언할 수 있습니다.
- STATIC: 정적 링킹 라이브러리 (*.a, *.lib)
  - 프로그램 실행 파일에 라이브러리 코드가 전부 들어 있는 것입니다.
- SHARED: 동적 링킹 라이브러리 (*.so, *.dll)
  - 프로그램 실행 파일에 라이브러리가 포함되어 있는 것이 아니라, 메모리에 라이브러리가 따로 올라가는데 이를 참조하는 형태입니다.
- MODULE: 동적으로 링크되지는 않지만, dlopen 과 같은 함수로 런타임 시에 불러올 수 있는 라이브러리입니다.
참고로 CMake 는 라이브러리를 만들게 되면 앞에 lib을 붙인 라이브러리 파일을 생성합니다.

+ 라이브러리 별칭 생성: 관리 용이

add_library(project::${PROJECT_NAME} ALIAS ${PROJECT_NAME})

라이브러리는 가급적 ALIAS를 추가하여 상용 *써드파티 제품과 같은 형태로 관리해주세요.
*써드파티: 다른 회사 제품에 이용되는 소프트웨어

주의!!!: 옛날 버전의 CMake 에서는 앞에 *target_ 이 빠진 include_directories, link_directories 와 같은 명령들이 사용되었는데 이는 최신의 CMake 에서는 사용이 권장되지 않는 명령들 입니다. 현재의 Modern CMake 패러다임은 타겟들을 기준으로 돌아가기 때문에 꼭 target_* 형태의 명령을 사용하도록 합시다.

+ 일부 파일로 실행파일 생성하기 (target_sources)

add_executable과 add_library의 한계는 소스 파일 목록을 한번에 결정해서 전달해야 한다는 점입니다.
이는 Target들이 CMakeList 파일의 끝부분에 나타나게 만들며, 2.x 버전 CMake들이 사용했던 방법처럼 List 변수를 사용해 소스파일 목록을 만들어야 하는 불편함이 있습니다.
따라서, CMake 3.x에서는 Target에 소스파일을 '추가'할 수 있도록 target_sources를 사용할 수 있습니다.

# preview 가 구현된 소스파일을 추가할지 결정하는 변수
set(USE_PREVIEW true)

# target: my_program
add_executable(my_program
    main.cpp
    feature1.cpp
)

target_sources(my_program
PRIVATE
    feature2.cpp
)
if(USE_PREVIEW)
    target_sources(my_program
    PRIVATE
        feature3_preview.cpp
    )
else()

+ 특정 위치의 파일 일괄 추가: include srcs

file(GLOB_RECURSE SRC_FILES CONFIGURE_DEPENDS
  ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp
)

add_library(shape STATIC ${SRC_FILES})

GLOB_RECURSE: 만일 하위 디렉토리를 포함하고 싶지 않다면 GLOB_RECURSE 대신에 GLOB 을 주면 됩니다.
SRC_FILES: 명령 내 포함된 파일들을 모두 모아서 SRC_FILES 라는 변수를 구성하라는 의미가 됩니다.
CONFIGURE_DEPENDS: 만약에 GLOB 으로 불러오는 파일 목록이 이전과 다를 경우 (예를 들어서 파일을 추가하거나 지웠을 때) CMake 를 다시 실행해서 빌드 파일을 재생성 하라는 의미가 됩니다.
- 만약에 디렉토리 안에 파일이 추가 되더라도, cmake .. 을 다시 실행할 필요 없이 그냥 make 만 실행해도 CMake 가 다시 실행되면서 빌드 파일을 재작성 합니다.

참조!!: CMake 에서 모든 변수들은 ${변수 이름} 과 같은 식으로 참조합니다.
make 와 비슷한데, make 는 소괄호 () 로 감싸주는 반면 CMake 는 중괄호 {} 로 감싸줍니다.
+ ${CMAKE_CURRENT_SOURCE_DIR}: CMakeLists.txt 가 위치한 디렉토리, 즉 현재 디렉토리를 의미 합니다.

속성(Property): compile options

target_compile_options(program PRIVATE -Wall -Werror)

-Wall : 모든 경고를 표시합니다.
-Werror : 경고는 컴파일 오류로 간주합니다.

+ include(CheckCXXCompilerFlag)

컴파일러 옵션을 지정해주기 전에, 컴파일러가 해당 옵션을 지원하는지 검사가 필요한 경우도 있습니다. CMake의 기본 모듈들 중에는 이를 지원하는 CheckCXXCompilerFlag라는 모듈이 있으며, 다음과 같이 검사합니다.

include(CheckCXXCompilerFlag)

check_cxx_compiler_flag(/std:c++latest  cxx_latest)
check_cxx_compiler_flag(-Wall           high_warning_level)

추가적인 컴파일 관련 내용은 [Github]CMake 할때 쪼오오금 도움이 되는 문서 를 참고하도록 합시다.

속성(Property): include directories

target_include_directories(one PUBLIC include)

상기 명령어는 타겟에 포함할 디렉토리를 추가합니다(대체로 헤더파일을 추가한다).

PUBLIC: 본 타겟에 의존하는 타겟들도 해당 디렉토리에 접근할 수 있습니다(의존성 전파).
PRAIVATE: 본 타겟에만 포함해야 하는 디렉토리를 다른 프로젝트에선 접근할 수 없습니다.

속성(Property): link library

target_link_libraries를 통해 타겟에 의존되어 있는 라이브러리를 명시하며, 주로 내부의 라이브러리나 FetchContent를 통해 받아온 외부 라이브러리를 링킹할 때 사용합니다.

#FetchContent로 받은 spdlog와 jsoncpp를 라이브러리에 링킹 작업(의존성 설정)
target_link_libraries(${PROJECT_NAME}
  PUBLIC
    spdlog::spdlog jsoncpp_static
  PRIVATE
    utf8proc
)

다른 프로젝트에서 상기의 ${PROJECT_NAME}에 해당하는 라이브러리를 링킹한 경우...

PUBLIC: 헤더파일을 include하기 위한 경로와 빌드 결과 생성되는 라이브러리에 접근할 수 있습니다.
PRAIVATE: 해당 프로젝트에서 사용하기 위해 추가한 라이브러리로 다른 프로젝트에선 접근할 수 없습니다.
INTERFACE: 헤더 파일에서만 사용하고 내부 구현에서는 사용하지 않습니다.
따라서...
- 의존성이 공유되어야 하거나 기타 라이브러리와 함께 사용하는 라이브러리라면 PUBLIC으로 선언하고,
- 내부 구현에만 사용되고 공개되지 않는 경우라면 PRIVATE에 배치하는 것이 적합합니다.
추가로...
- FetchContent를 이용하여 외부 라이브러리를 가져오는 방법은 다음 글을 참조하도록 합시다!
- 참고: [CMake] FetchContent: 외부 라이브러리를 사용하자~

간단 예제

다음은 상기 설명들을 포함하는 최소한의 CMake 예제이며, 결과로서 'backlib'이라는 정적 라이브러리 파일이 생성됩니다.

cmake_minimum_required(VERSION 3.22)
# ${PROJECT_NAME}: backlib
project(backlib VERSION 1.0
                  DESCRIPTION "Util Library"
                  LANGUAGES CXX C)

# CONFIGURE_DEPENDS: main build system check target to rerun the flagged GLOB commands at build time.
file(GLOB DEPS CONFIGURE_DEPENDS "src/*")
set(ALL_DEPS ${ALL_DEPS} ${DEPS})

# ${PROJECT_NAME}와 autocrypt::${PROJECT_NAME}를 라이브러리에 추가
add_library(${PROJECT_NAME} STATIC ${ALL_DEPS})
# add_library(autocrypt::${PROJECT_NAME} ALIAS ${PROJECT_NAME})

target_include_directories(${PROJECT_NAME}
  PUBLIC
    include 
    ${PROJECT_BINARY_DIR}/include
)

#FetchContent로 받은 spdlog와 jsoncpp를 라이브러리에 링킹 작업(의존성 설정)
target_link_libraries(${PROJECT_NAME}
  PUBLIC
    spdlog::spdlog jsoncpp_static
)

3.3 변수(Variables)와 캐시(Cache)

지역변수(Local Variables) 설정

변수는 set을 사용해서 생성하며 단순한 Boolean, 문자열, 파일 경로, 리스트 등을 표현할 수 있습니다.
또한, unset을 사용해서 제거할 수 있습니다.

set(MY_VARIABLE "value")
set(MY_LIST "one" "two")
set(MY_LIST "one;two")
set(MY_BOOL ON)

option(MY_BOOL "message" OFF)

이러한 변수를 message와 ${}를 이용하면 출력하여 변수값을 문자열로 확인할 수 있습니다.

set(CMAKE_BUILD_TYPE Debug)

message(STATUS CMAKE_BUILD_TYPE)                     # -- CMAKE_BUILD_TYPE
message(STATUS ${CMAKE_BUILD_TYPE})                  # -- Debug
message(STATUS "Configuration: ${CMAKE_BUILD_TYPE}") # -- Configuration: Debug

+ message: 스크립트를 실행하며 해당 라인에 왔을 때 해당 정보를 출력합니다.

message([<mode>] "message text" ...)

<mode> keyword: optional

NOTICE : <mode> 생략시 default <mode>값이며, 중요 정보를 나타내는 메세지로 구분하여 출력
STATUS : 상태메세지 출력 ('--'와 함께 메세지가 출력됨)
WARNING : 경고 메세지
AUTHOR_WARNING : 스크립트 개발자용 경고 메세지
SEND_ERROR : 오류 메세지, 오류가 나도 계속 진행하지만 결과물(Makefile)은 생성하지 않음
FATAL_ERROR : 오류 메세지, 빌드작업을 즉시 중단
- 주의!!! : Makefile 실행 시가 아닌 cmake로 Makefile을 생성할 때 출력되는 메세지입니다.

캐시(Cache) 설정

커맨드 라인을 통한 변수 설정은 Cache를 통해 지원됩니다.

set(MY_CACHE_VARIABLE "VALUE" CACHE STRING "Description")

+ 캐시(Cache) 확인 및 설정

$ nano CMakeCaches.txt

$ ccmake ..

ccmake: MY_CACHE_VARIABLE과 같은 configuration 설정값을 확인 및 변경 가능.
참고: https://cmake.org/cmake/help/latest/manual/ccmake.1.html

환경변수(Environment Variables) 설정

# SET 
set(ENV{variable_name} value)
# GET 
$ENV{variable_name}

프로퍼티(Properties) 설정

CMake가 정보를 저장하는 방식에는 변수 외에도 프로퍼티가 있습니다. 프로퍼티는 타겟 별로 지정 가능합니다.

set_property(TARGET TargetName PROPERTY CXX_STANDARD 11)
set_target_properties(TargetName PROPERTIES CXX_STANDARD 11)

get_property(ResultVariable TARGET TargetName PROPERTY CXX_STANDARD)

3.4 CMake 프로그래밍

CMake는 일부 간단한 프로그래밍을 지원합니다.

if 문

if(variable)
    # If variable is `ON`, `YES`, `TRUE`, `Y`, or non zero number
else()
    # If variable is `0`, `OFF`, `NO`, `FALSE`, `N`, `IGNORE`, `NOTFOUND`, `""`, or ends in `-NOTFOUND`
endif()
# If variable does not expand to one of the above, CMake will expand it then try again

Generator-expressions

target_compile_options(MyTarget PRIVATE "$<$<CONFIG:Debug>:--my-flag>")

매크로(Macros) 및 함수(Functions)

function(SIMPLE REQUIRED_ARG)
    message(STATUS "Simple arguments: ${REQUIRED_ARG}, followed by ${ARGV}")
    set(${REQUIRED_ARG} "From SIMPLE" PARENT_SCOPE)
endfunction()

simple(This)
message("Output: ${This}")

함수(function)와 관련된 자세한 내용은 [CMake] function: 반복되는 작업은 함수화하자!를 참고합시다.

3.5 코드와 소통하기: CMakeLists 정의된 변수 코드에서 사용하기

CMake는 configure_file 명령어를 통해 cpp, hpp등 코드를 직접 수정할 수 있습니다. 가장 많이 사용되는 예시는 Version.h.in 입니다.

Configure File 설정 파일 생성: Version.h.in

#pragma once

#define MY_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
#define MY_VERSION_MINOR @PROJECT_VERSION_MINOR@
#define MY_VERSION_PATCH @PROJECT_VERSION_PATCH@
#define MY_VERSION_TWEAK @PROJECT_VERSION_TWEAK@
#define MY_VERSION "@PROJECT_VERSION@"

Configure File 설정 파일 명시

configure_file (
    "${PROJECT_SOURCE_DIR}/include/My/Version.h.in"
    "${PROJECT_BINARY_DIR}/include/My/Version.h"
)

파일의 내용을 읽어오는 것도 가능합니다.

# Assuming the canonical version is listed in a single line
# This would be in several parts if picking up from MAJOR, MINOR, etc.
set(VERSION_REGEX "#define MY_VERSION[ \t]+\"(.+)\"")

# Read in the line containing the version
file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/include/My/Version.hpp"
    VERSION_STRING REGEX ${VERSION_REGEX})

# Pick out just the version
string(REGEX REPLACE ${VERSION_REGEX} "\\1" VERSION_STRING "${VERSION_STRING}")

# Automatically getting PROJECT_VERSION_MAJOR, My_VERSION_MAJOR, etc.
project(My LANGUAGES CXX VERSION ${VERSION_STRING})

3.6 다른 프로그램 실행시키기

다른 프로그램을 실행시키는 방법은 2가지가 있습니다.

설정 시간(configure time)에 외부 프로그램을 실행시키는 방법: execute_process

find_package(Git QUIET)

if(GIT_FOUND AND EXISTS "${PROJECT_SOURCE_DIR}/.git")
    execute_process(COMMAND ${GIT_EXECUTABLE} submodule update --init --recursive
                    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
                    RESULT_VARIABLE GIT_SUBMOD_RESULT)
    if(NOT GIT_SUBMOD_RESULT EQUAL "0")
        message(FATAL_ERROR "git submodule update --init failed with ${GIT_SUBMOD_RESULT}, please checkout submodules")
    endif()
endif()

빌드 시간(build time)에 외부 프로그램을 실행시키는 방법: add_custom_command...

find_package(PythonInterp REQUIRED)
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/include/Generated.hpp"
    COMMAND "${PYTHON_EXECUTABLE}" "${CMAKE_CURRENT_SOURCE_DIR}/scripts/GenerateHeader.py" --argument
    DEPENDS some_target)

add_custom_target(generate_header ALL
    DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/include/Generated.hpp")

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/include/Generated.hpp DESTINATION include)

3.7 다른 라이브러리 가져오기: find_package, FetchContent

설정 시간(configure time)에 외부 라이브러리를 가져오는 방법: FetchContent

FetchContent_Declare(
  <name>
  <contentOptions>...
  [OVERRIDE_FIND_PACKAGE |
   FIND_PACKAGE_ARGS args...]
)
FetchContent_MakeAvilable(<name>)

`FetchContent_MakeAvailable` was introduced in CMake 3.14
FetchContent에 대한 자세한 설명은 [CMake] FetchContent: 외부 라이브러리를 사용하자~ 를 참고하시기 바랍니다.

빌드 시간(build time)에 외부 라이브러리를 가져오는 방법: ExternalProject_Add()

ExternalProject_Add(example
  ... # Download options, etc.
  BUILD_COMMAND ${CMAKE_COMMAND} -E echo "Starting $<CONFIG> build"
  COMMAND       ${CMAKE_COMMAND} --build <BINARY_DIR> --config $<CONFIG>
  COMMAND       ${CMAKE_COMMAND} -E echo "$<CONFIG> build complete"
)

3.8 CMake 간단 예제

다음은 상기 설명들을 포함하는 CMake 간단한 예제(주석 포함) 입니다.

# Almost all CMake files should start with this
# You should always specify a range with the newest
# and oldest tested versions of CMake. This will ensure
# you pick up the best policies.
cmake_minimum_required(VERSION 3.1...3.20)

# This is your project statement. You should always list languages;
# Listing the version is nice here since it sets lots of useful variables
project(
  ModernCMakeExample
  VERSION 1.0
  LANGUAGES CXX)

# If you set any CMAKE_ variables, that can go here.
# (But usually don't do this, except maybe for C++ standard)

# Find packages go here.

# You should usually split this into folders, but this is a simple example

# This is a "default" library, and will match the *** variable setting.
# Other common choices are STATIC, SHARED, and MODULE
# Including header files here helps IDEs but is not required.
# Output libname matches target name, with the usual extensions on your system
add_library(MyLibExample simple_lib.cpp simple_lib.hpp)

# Link each target with other targets or add options, etc.

# Adding something we can run - Output name matches target name
add_executable(MyExample simple_example.cpp)

# Make sure you link your targets with this command. It can also link libraries and
# even flags, so linking a target that does not exist will not give a configure-time error.
target_link_libraries(MyExample PRIVATE MyLibExample)

4. Do & Don't

다음 항목들은 An Introduction to Modern CMake: Do's and Don't, [CMake] Effective Modern CMake 정리를 참고하여 작성하였습니다. 하기 목록만으로는 이해가 어려울 수 있습니다. 보다 심도있는 이해를 원할 경우 원문을 참조해주세요.

Do

CMake도 코드라고 생각하고 깔끔하고 읽을 수 있게 유지하시오
target 기반으로 생각하시오
- Your targets should represent concepts. Make an (IMPORTED) INTERFACE target for anything that should stay together and link to that.
interface를 내보내시오
Config.cmake 파일을 작성하시오
- This is what a library author should do to support clients.
ALIAS를 작성하시오
- Using add_subdirectory and find_package should provide the same targets and namespaces.
매크로 대신 펑션을 사용하시오
함수명은 소문자를 사용하고, 변수명에 대문자를 사용하시오
cmake_policy를 사용하고 versions의 범위를 설정하시오.
- Policies change for a reason. Only piecemeal set OLD policies if you have to.

Don't

전역 펑션을 사용하지 마시오: link_directories, include_libraries 등 사용하지 마시오.
불필요한 PUBLIC 한정자 내 항목을 추가하지 마시오
- You should avoid forcing something on users that is not required (-Wall). Make these PRIVATE instead.
GLOB로 파일을 선택하지 마시오
- Make or another tool will not know if you add files without rerunning CMake.
- Note that CMake 3.12 adds a CONFIGURE_DEPENDS flag that makes this far better if you need to use it.
타겟 작성 없이 LINK하지 마시오
LINK시 PUBLIC/PRIVATE를 생략하지 마시오

참고

[Blog] Effective Modern CMake: https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
[Blog] An Introduction to Modern CMake: https://cliutils.gitlab.io/modern-cmake/
[Blog] C++ 프로젝트를 위한 CMake 사용법: https://modoocode.com/332
참고할만한 CMake 프로젝트
[Github]CMake 할때 쪼오오금 도움이 되는 문서:
https://gist.github.com/luncliff/6e2d4eb7ca29a0afd5b592f72b80cb5c?permalink_comment_id=3037466

저작자표시 비영리 변경금지

'Study: DeveloperTools(DevTool) > DevTool: CMake' 카테고리의 다른 글

[CMake] FetchContent: 외부 라이브러리를 사용하자~ (0)	2022.06.24
[CMake] Effective Modern CMake 정리 (0)	2022.06.24
[CMake] CMake 소개 및 필요성: Modern CMake 3.23+ (0)	2022.06.24
[CMake] Makefile 및 CMake의 필요성 정리 (2)	2022.06.24
[C++] C++ 빌드 시스템(툴)에는 뭐가 있을까? (0)	2022.06.24

« 2024/11 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30