반응형
Cygwin + VS Code C++ 개발자를 위한 쉬운 가이드
Cygwin 환경과 VS Code를 사용해 C++ 개발을 시작한 학생 여러분, 혹은 이제 막 CMake를 접하고 어려움을 느끼는 분들을 위해 이 글을 작성했습니다. CMakeLists.txt 파일, 왜 써야 하는지, 어떻게 작성하는지 막막하게 느껴질 수 있습니다.
이 글을 통해 CMake의 기본적인 개념부터 실제 프로젝트 적용 사례까지 차근차근 알아볼 것입니다.
(1) CMake, 왜 필요할까요?
우리가 C++ 코드를 작성하면, 컴퓨터가 이해할 수 있는 기계어 코드로 바꿔주는 '컴파일' 과정과 여러 코드 파일을 하나로 묶는 '링크' 과정이 필요합니다. 이걸 '빌드'라고 하죠.
프로젝트가 작을 때는 터미널에서 직접 컴파일 명령어를 입력할 수 있습니다. 예를 들어 Cygwin 터미널에서 g++ main.cpp -o my_program 처럼요.
하지만 파일이 많아지고, 외부 라이브러리(다른 사람이 만든 코드 묶음)를 사용하고, 윈도우, 리눅스, 맥 등 다양한 환경에서 빌드해야 한다면 어떨까요?
- 복잡성 증가: 수십, 수백 개의 파일을 일일이 명령어로 관리하기는 매우 어렵습니다.
- 플랫폼 의존성: 윈도우와 리눅스/맥은 컴파일/링크 방식이나 라이브러리 사용법이 다를 수 있습니다.
- 종속성 관리: 프로젝트가 사용하는 외부 라이브러리를 찾고 설정하는 과정이 복잡합니다.
CMake는 바로 이런 문제들을 해결해주는 빌드 시스템 생성 도구(Build System Generator)입니다.
- 플랫폼 독립성: CMakeLists.txt라는 설정 파일 하나만 잘 작성해두면, CMake가 각 운영체제(윈도우, 리눅스, 맥)에 맞는 빌드 파일(예: Makefile, Ninja 파일, Visual Studio 솔루션 파일 등)을 자동으로 생성해줍니다.
- 간편한 빌드: 생성된 빌드 파일을 이용해 간단한 명령어(예: make, ninja) 만으로 전체 프로젝트를 빌드할 수 있습니다.
- 종속성 관리: find_package 같은 명령어로 외부 라이브러리를 쉽게 찾아 프로젝트에 연결할 수 있습니다. (예: Google Test)
- 프로젝트 구조화: 소스 파일, 헤더 파일, 테스트 코드를 분리하여 관리하기 용이합니다.
- IDE 통합: VS Code의 'CMake Tools' 확장 기능처럼 IDE와 잘 연동되어 빌드, 실행, 디버깅 과정을 더욱 편리하게 만듭니다.
결론적으로, CMake를 사용하면 복잡한 C++ 프로젝트의 빌드 과정을 자동화하고 표준화하여 개발 생산성을 크게 높일 수 있습니다. 처음에는 조금 어렵게 느껴질 수 있지만, 한번 익숙해지면 CMake 없는 개발은 상상하기 어려울 것입니다!
(2) CMakeLists.txt 기본 문법 살펴보기
CMakeLists.txt 파일은 CMake에게 "우리 프로젝트를 어떻게 빌드해야 하는지" 알려주는 설명서 또는 스크립트입니다. 몇 가지 핵심적인 명령어와 변수를 알아봅시다.
- #: 주석입니다. # 뒤에 오는 내용은 CMake가 무시하며, 설명을 위해 사용합니다.
- cmake_minimum_required(VERSION 3.10): 이 프로젝트를 빌드하는 데 필요한 최소 CMake 버전을 지정합니다. 하위 버전 CMake에서는 빌드가 안 될 수 있으므로 호환성을 위해 명시하는 것이 좋습니다.
- project(프로젝트이름 [VERSION 1.0] [LANGUAGES CXX]): 프로젝트의 이름, 버전, 사용할 프로그래밍 언어(C++는 CXX) 등을 정의합니다. 이 명령어를 사용하면 PROJECT_NAME, PROJECT_SOURCE_DIR 같은 유용한 변수들이 자동으로 설정됩니다.
- set(변수이름 값1 값2 ...): CMake 변수를 설정합니다. 소스 파일 목록 등을 변수로 만들어 관리하면 편리합니다.
- 예: set(SOURCES main.cpp utils.cpp)
- add_executable(실행파일이름 소스파일1 소스파일2 ...): 소스 파일들을 컴파일하고 링크하여 실행 파일을 만드는 규칙을 정의합니다.
- 예: add_executable(my_app ${SOURCES}) - 위에서 정의한 SOURCES 변수를 사용합니다.
- add_library(라이브러리이름 [STATIC | SHARED] 소스파일1 ...): 소스 파일들을 컴파일하여 라이브러리 파일(.a, .lib, .so, .dll 등)을 만드는 규칙을 정의합니다. 코드를 모듈화할 때 유용합니다.
- STATIC: 정적 라이브러리 (빌드 시 실행 파일에 포함됨)
- SHARED: 동적 라이브러리 (실행 시 필요함)
- target_include_directories(타겟이름 [PUBLIC | PRIVATE | INTERFACE] 경로1 경로2 ...): 특정 타겟(실행 파일 또는 라이브러리)을 빌드할 때 필요한 헤더 파일(.h, .hpp)의 경로를 지정합니다. 컴파일러가 #include한 파일을 찾을 수 있도록 돕습니다.
- PRIVATE: 이 타겟 내부에서만 필요한 헤더 경로.
- PUBLIC: 이 타겟 내부에서도 필요하고, 이 타겟을 사용하는 다른 타겟에서도 필요한 헤더 경로.
- INTERFACE: 이 타겟을 사용하는 다른 타겟에서만 필요한 헤더 경로. (보통 헤더 전용 라이브러리에 사용)
- target_link_libraries(타겟이름 [PUBLIC | PRIVATE | INTERFACE] 라이브러리1 라이브러리2 ...): 특정 타겟이 의존하는 다른 라이브러리들을 링크하도록 지정합니다.
- 예: target_link_libraries(my_app PRIVATE my_lib other_lib) - my_app을 만들 때 my_lib과 other_lib을 연결합니다.
- find_package(패키지이름 [REQUIRED] [COMPONENTS ...]): 시스템에 설치된 외부 라이브러리(패키지)를 찾습니다. REQUIRED를 붙이면 해당 패키지를 찾지 못했을 때 오류를 발생시킵니다.
- 예: find_package(Boost 1.66 REQUIRED COMPONENTS program_options)
- add_subdirectory(하위폴더명): 지정된 하위 폴더에 있는 CMakeLists.txt 파일을 읽어 처리합니다. 프로젝트 구조가 복잡해질 때 사용합니다.
- include(FetchContent) / WorkspaceContent_Declare(...) / WorkspaceContent_MakeAvailable(...): 외부 라이브러리를 빌드 시점에 다운로드하고 빌드하여 사용할 수 있게 해주는 최신 기능입니다. (Google Test 예제에서 사용)
- enable_testing(): CTest (CMake에 내장된 테스트 프레임워크)를 활성화합니다.
- add_test(NAME 테스트이름 COMMAND 실행할명령): CTest로 실행할 테스트 케이스를 정의합니다.
위의 모든 명령어나 변수가 하나의 CMakeLists.txt에 다 포함되지는 않습니다. 필요한 사항을들 추가하면됩니다. 이제 실제 프로젝트 예제를 통해 이 명령어들이 어떻게 사용되는지 봅겠습니다.
예제 1: 단순한 프로젝트 (project1)
가장 기본적인 형태입니다. 모든 파일이 하나의 폴더 안에 있습니다.
프로젝트 구조:
project1/
├── CMakeLists.txt
└── main.cpp
main.cpp 내용:
#include <iostream>
int main() {
std::cout << "Hello, CMake from project1!" << std::endl;
return 0;
}
CMakeLists.txt 내용:
# 1. 최소 CMake 버전 설정
cmake_minimum_required(VERSION 3.10)
# 2. 프로젝트 이름 및 언어 설정 (C++)
project(Project1 LANGUAGES CXX)
# 3. 실행 파일 생성 규칙 정의
# 이름: hello_cmake
# 사용될 소스 파일: main.cpp
add_executable(hello_cmake main.cpp)
# (선택 사항) C++ 표준 설정 (예: C++17)
# target_compile_features(hello_cmake PUBLIC cxx_std_17)
[설명]:
- cmake_minimum_required: CMake 3.10 이상 버전이 필요하다고 명시합니다.
- project: 프로젝트 이름을 Project1으로 하고, C++(CXX)를 사용한다고 설정합니다.
- add_executable: main.cpp 파일을 컴파일하고 링크해서 hello_cmake라는 실행 파일을 만들라고 지시합니다.
이 CMakeLists.txt 파일이 있는 project1 폴더에서 VS Code를 열거나, Cygwin 터미널에서 다음 명령어를 실행하면 빌드할 수 있습니다.
# 1. 빌드용 폴더 생성 및 이동 (소스 폴더와 분리하는 것이 좋음)
mkdir build
cd build
# 2. CMake 실행 (빌드 시스템 생성. 여기서는 Makefile이 생성됨)
# ".."는 상위 폴더에 CMakeLists.txt가 있다는 의미
cmake ..
# 3. 빌드 실행 (Makefile 실행)
make빌드가 성공하면 project1/build 폴더 안에 hello_cmake.exe 파일이 생성됩니다.
예제 2: 소스(src)와 테스트(test) 분리 및 Google Test 사용 (project2)
조금 더 일반적인 프로젝트 구조입니다. 소스 코드(src), 헤더 파일(include), 테스트 코드(test)를 분리하고, 외부 라이브러리인 Google Test를 사용하여 유닛 테스트를 작성하는 경우입니다.
프로젝트 구조:
project2/
├── CMakeLists.txt # 최상위 CMakeLists.txt
├── include/ # 헤더 파일 폴더
│ └── math_utils.h
├── src/ # 소스 코드 폴더
│ ├── CMakeLists.txt # src 폴더용 CMakeLists.txt
│ └── math_utils.cpp
└── test/ # 테스트 코드 폴더
├── CMakeLists.txt # test 폴더용 CMakeLists.txt
└── math_utils_test.cpp
include/math_utils.h 내용:
#ifndef MATH_UTILS_H
#define MATH_UTILS_H
int add(int a, int b);
#endif // MATH_UTILS_H
src/math_utils.cpp 내용:
#include "math_utils.h" // "../include/math_utils.h" 가 아님! include 경로는 CMake가 설정
int add(int a, int b) {
return a + b;
}
test/math_utils_test.cpp 내용 (Google Test 사용):
#include "gtest/gtest.h" // Google Test 헤더
#include "math_utils.h" // 테스트할 코드의 헤더
// add 함수 테스트 케이스
TEST(MathUtilsTest, Add) {
EXPECT_EQ(add(1, 2), 3);
EXPECT_EQ(add(-1, 1), 0);
EXPECT_EQ(add(0, 0), 0);
}
// main 함수는 Google Test가 알아서 처리해 줍니다 (GTest::gtest_main 링크 시)
이제 각 CMakeLists.txt 파일을 다음과 같이 작성합니다.
단 외부 라이브러리 사용하는 부분에서 위치나 작성 방법을 여러가지로 작성될 수 있습니다. 예제 사용되는 google test 라이브러리 경우를 예로 들어 본다면 설치하는 방법은 다양합니다. [더보기 글을 통해 다양한 방법을 확인하세요.]
더보기
더보기
Google Test 라이브러리를 가져오는 방법은 여러 가지가 있으며, WorkspaceContent 관련 코드를 test/CMakeLists.txt에 작성하는 것도 가능합니다. 각각 살펴본 후 다양한 방법으로도 사용해 보며 라이브러리 연동하는 방법을 이해하세요.
(1) Google Test 라이브러리 가져오는 다른 방법들
WorkspaceContent는 CMake 3.11 이상에서 외부 라이브러리를 빌드 시점에 다운로드하고 통합하는 편리한 방법이지만, 유일한 방법은 아닙니다. 다른 일반적인 방법들은 다음과 같습니다.
- 시스템에 설치된 Google Test 사용 (find_package):
- 개발 환경(예: Cygwin, Linux, macOS, Windows)에 Google Test를 미리 설치합니다. (패키지 매니저 apt, brew, pacman 등을 사용하거나, 소스를 직접 빌드하여 설치)
- CMakeLists.txt에서는 find_package 명령어를 사용하여 시스템에 설치된 Google Test를 찾습니다.
# 시스템에서 Google Test 패키지를 찾습니다. # REQUIRED: 찾지 못하면 에러 발생 find_package(GTest REQUIRED) # ... 이후 test/CMakeLists.txt 에서 ... target_link_libraries(run_tests PRIVATE GTest::gtest GTest::gtest_main)- 장점: CMake 설정이 간결해집니다. 시스템 라이브러리를 활용합니다.
- 단점: 모든 개발자가 동일한 버전의 Google Test를 미리 설치해야 하는 번거로움이 있습니다. 환경 설정에 의존하게 됩니다.
- Git Submodule 사용:
- 프로젝트 Git 저장소에 Google Test 저장소를 서브모듈로 추가합니다. (git submodule add ...)
- 최상위 CMakeLists.txt에서 add_subdirectory를 사용하여 서브모듈 경로를 추가합니다.
# 최상위 CMakeLists.txt # ... # googletest 서브모듈이 external/googletest 에 있다고 가정 set(GTEST_SKIP_INSTALL ON) # 설치 건너뛰기 설정은 여전히 유용 add_subdirectory(external/googletest) # ... add_subdirectory(test)- 장점: 프로젝트 저장소 내에서 Google Test 버전을 명확히 관리할 수 있습니다. WorkspaceContent보다 오래된 CMake 버전에서도 사용 가능합니다.
- 단점: Git 서브모듈 관리가 추가로 필요합니다. (git submodule update --init 등)
- 소스 코드 직접 포함:
- Google Test 소스 코드를 다운로드하여 프로젝트 폴더 내의 특정 디렉토리(예: external/googletest)에 복사해 넣습니다.
- Git Submodule 방식과 유사하게 add_subdirectory를 사용합니다.
# 최상위 CMakeLists.txt # ... # googletest 소스코드가 external/googletest 에 있다고 가정 set(GTEST_SKIP_INSTALL ON) add_subdirectory(external/googletest) # ... add_subdirectory(test)- 장점: 외부 의존성 없이 프로젝트 자체만으로 빌드가 가능합니다. (인터넷 연결 불필요)
- 단점: Google Test 버전을 업데이트하기 번거롭습니다. 프로젝트 저장소 크기가 커질 수 있습니다.
- 패키지 매니저 사용 (vcpkg, Conan 등):
- vcpkg나 Conan 같은 C++ 패키지 매니저를 사용하여 Google Test를 설치하고 관리합니다.
- CMake에서는 해당 패키지 매니저가 제공하는 방식으로 find_package를 사용합니다. (예: vcpkg 사용 시 CMake Toolchain 파일 지정)
- 장점: 복잡한 의존성 관리에 용이합니다. 다양한 라이브러리를 일관된 방식으로 관리할 수 있습니다.
- 단점: 해당 패키지 매니저를 별도로 설치하고 사용법을 익혀야 합니다.
WorkspaceContent는 이러한 방법들의 장점을 일부 결합한 방식으로, CMake 자체 기능만으로 외부 의존성을 빌드 시점에 가져와 통합할 수 있어 최근 많이 선호되고 있습니다.
(2) WorkspaceContent 관련 코드를 test/CMakeLists.txt에 작성하는 것
googletest는 test 폴더에서 필요하므로 관련된 것을 test/CMakeLists에 작성할 수도 있습니다.
test/CMakeLists.txt 파일 내에서 include(FetchContent), WorkspaceContent_Declare(...), WorkspaceContent_MakeAvailable(...)을 호출할 수 있습니다.
test/CMakeLists.txt 예시:
# test/CMakeLists.txt 내부에 FetchContent 로직 포함
# Google Test 가져오기 (이 파일 내에서만 수행)
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.14.0
)
set(GTEST_SKIP_INSTALL ON)
FetchContent_MakeAvailable(googletest)
# CTest 활성화 (테스트 실행을 위해)
# enable_testing() # enable_testing()은 보통 최상위에서 한 번만 호출합니다.
add_executable(run_tests math_utils_test.cpp)
# 링크: FetchContent_MakeAvailable 이후이므로 GTest::gtest 사용 가능
target_link_libraries(run_tests PRIVATE math_lib GTest::gtest GTest::gtest_main)
# CTest에 테스트 추가
add_test(NAME MathUtilTests COMMAND run_tests)
그러나 일부 개발자들의 의견들로 최상위 CMakeLists.txt에서 외부 의존성을 관리하는 것이 더 좋은 방법으로 여기기도 합니다. 그 이유는 다음과 같습니다.
- 중앙 집중 관리: 프로젝트 전체에서 사용하는 모든 외부 라이브러리(Google Test 포함)를 최상위 CMakeLists.txt 한 곳에서 선언하고 관리하는 것이 프로젝트의 구조를 파악하고 유지보수하기에 더 용이합니다. 의존성을 찾기 위해 여러 하위 폴더의 CMakeLists 파일을 뒤질 필요가 없습니다.
- 빌드 순서 및 가용성: 최상위에서 WorkspaceContent_MakeAvailable(googletest)를 먼저 호출하고 add_subdirectory(test)를 나중에 호출하면, test/CMakeLists.txt가 처리될 시점에는 Google Test 타겟(GTest::gtest, GTest::gtest_main)이 이미 사용 가능한 상태임이 보장됩니다. 로직이 분산되면 빌드 순서에 따른 미묘한 문제를 야기할 수도 있습니다. (물론 위 예시처럼 test 내부에서 순서대로 호출하면 문제는 없습니다.)
- 재사용성 및 일관성: 만약 Google Test가 아닌 다른 라이브러리이고, 이 라이브러리가 test 폴더뿐만 아니라 다른 하위 프로젝트에서도 필요하다면, 각 하위 폴더마다 WorkspaceContent를 호출하는 것은 비효율적입니다. 최상위에서 한 번만 처리하는 것이 좋습니다. Google Test는 주로 test에서만 쓰이지만, 일관된 구조를 유지하는 차원에서 다른 라이브러리들과 동일하게 최상위에서 관리하는 것이 좋습니다.
- 명확성: 최상위 CMakeLists는 "이 프로젝트는 이러한 외부 요소들을 필요로 한다"는 명세를 담고, 하위 CMakeLists는 "이 요소들을 사용하여 구체적으로 무엇을 빌드한다"는 역할을 나누는 것이 더 명확한 구조입니다.
결론:
다양한 방법들을 이해하고 사용해서 원하는 방법을 선택하도록 합니다.
project2/CMakeLists.txt (최상위):
cmake_minimum_required(VERSION 3.14) # FetchContent는 3.11 이상 필요, 3.14 권장
project(Project2 LANGUAGES CXX)
# Google Test 라이브러리 가져오기 (FetchContent 사용)
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.14.0 # 특정 버전 명시 권장
)
# GTEST_SKIP_INSTALL=ON: googletest 설치 과정은 건너뜀 (빌드 시에만 필요)
set(GTEST_SKIP_INSTALL ON)
FetchContent_MakeAvailable(googletest)
# CTest 활성화 (테스트 실행을 위해)
enable_testing()
# 하위 폴더의 CMakeLists.txt 처리
add_subdirectory(src)
add_subdirectory(test)
project2/src/CMakeLists.txt:
# math_utils.cpp 소스 파일로 정적 라이브러리(math_lib) 생성
add_library(math_lib STATIC math_utils.cpp)
# math_lib 라이브러리가 필요로 하는 헤더 파일 경로 설정
# PUBLIC: math_lib 자체도 이 헤더가 필요하고, math_lib을 사용하는 다른 타겟(예: 테스트 코드)도 이 헤더 경로를 알아야 함
# ${PROJECT_SOURCE_DIR}은 최상위 CMakeLists.txt가 있는 폴더 경로 (즉, project2/)
target_include_directories(math_lib PUBLIC ${PROJECT_SOURCE_DIR}/include)
project2/test/CMakeLists.txt:
# 테스트 실행 파일(run_tests) 생성
add_executable(run_tests math_utils_test.cpp)
# 테스트 실행 파일(run_tests)에 필요한 라이브러리 링크
# PRIVATE: run_tests 내부적으로만 필요한 링크
# 1. math_lib: 우리가 만든 라이브러리
# 2. GTest::gtest: Google Test 라이브러리 (테스트 기능 제공)
# 3. GTest::gtest_main: Google Test의 main 함수를 포함하는 라이브러리
target_link_libraries(run_tests PRIVATE math_lib GTest::gtest GTest::gtest_main)
# CTest에 테스트 추가
# 이름: MathUtilTests
# 실행할 명령: run_tests (위에서 만든 실행 파일)
add_test(NAME MathUtilTests COMMAND run_tests)
[설명]
- 최상위 CMakeLists.txt:
- WorkspaceContent를 사용하여 GitHub에서 Google Test 소스 코드를 다운로드하고 빌드 준비를 합니다. CMake가 알아서 처리해주므로 매우 편리합니다.
- enable_testing()으로 CTest를 활성화합니다.
- add_subdirectory를 사용해 src 폴더와 test 폴더의 CMakeLists.txt를 순서대로 처리하도록 지시합니다.
- src/CMakeLists.txt:
- add_library로 math_utils.cpp를 컴파일하여 math_lib라는 정적 라이브러리를 만듭니다.
- target_include_directories로 math_lib와 이 라이브러리를 사용하는 다른 타겟이 include/ 폴더의 헤더 파일을 찾을 수 있도록 설정합니다. ${PROJECT_SOURCE_DIR} 변수를 사용하여 전체 경로를 명시하는 것이 좋습니다. PUBLIC으로 지정했기 때문에, 나중에 test 폴더에서 math_lib를 링크할 때 include 경로가 자동으로 전달됩니다.
- test/CMakeLists.txt:
- add_executable로 테스트 코드를 컴파일하여 run_tests 실행 파일을 만듭니다.
- target_link_libraries로 run_tests를 빌드할 때 필요한 라이브러리들을 연결합니다.
- math_lib: 우리가 src에서 만든 라이브러리. add 함수 구현이 들어있습니다.
- GTest::gtest와 GTest::gtest_main: Google Test 라이브러리입니다. WorkspaceContent_MakeAvailable(googletest) 명령을 통해 사용할 수 있게 된 타겟 이름입니다. (gtest_main은 테스트 실행을 위한 main 함수를 제공합니다.)
- add_test로 CTest가 실행할 테스트를 정의합니다. make test 또는 ctest 명령어로 실행할 수 있습니다.
빌드 방법은 project1과 동일합니다.
project2 폴더에서 build 폴더를 만들고 그 안에서 cmake .. 와 make를 실행하면 src 라이브러리와 test 실행 파일이 모두 빌드됩니다. 테스트는 make test 또는 ctest 명령으로 실행할 수 있습니다.
# 1. 빌드용 폴더 생성 및 이동 (소스 폴더와 분리하는 것이 좋음)
mkdir build
cd build
# 2. CMake 실행 (빌드 시스템 생성. 여기서는 Makefile이 생성됨)
# ".."는 상위 폴더에 CMakeLists.txt가 있다는 의미
cmake ..
# 3. 빌드 실행 (Makefile 실행)
make
# 4. 실행
make test 또는 cmakeVS Code 와 CMake 연동
VS Code에서 C++ 개발 시 "CMake Tools" 확장 기능을 설치하면 CMake 사용이 훨씬 편리해집니다.
- 확장 기능 설치: VS Code 마켓플레이스에서 "CMake Tools"를 검색하여 설치합니다.
- 프로젝트 열기: CMakeLists.txt 파일이 있는 프로젝트 폴더 (예: project1 또는 project2)를 VS Code에서 엽니다.
- 자동 감지: CMake Tools가 CMakeLists.txt 파일을 자동으로 감지하고 초기 설정을 시도합니다.
- 키트(Kit) 선택: VS Code 하단 상태 표시줄에 "No active kit" 또는 현재 선택된 키트가 표시됩니다. 클릭하여 사용할 컴파일러 환경(Kit)을 선택합니다. Cygwin GCC/G++ 환경을 설치했다면 관련 키트가 목록에 나타날 것입니다. (예: GCC for x86_64-pc-cygwin)
- Configure: 키트를 선택하면 CMake Tools가 자동으로 cmake .. (또는 유사한) 명령을 실행하여 빌드 파일을 생성하는 'Configure' 단계를 수행합니다. 상태 표시줄의 [CMake: Ready] 또는 유사한 메시지로 확인할 수 있습니다. 문제가 발생하면 출력(Output) 패널의 CMake/Build 로그를 확인하세요.
- Build: 상태 표시줄의 Build 버튼(보통 렌치 아이콘 옆)을 클릭하거나, F7 키를 누르거나, 명령 팔레트(Ctrl+Shift+P)에서 CMake: Build를 실행하여 프로젝트를 빌드합니다. (make 또는 ninja 명령 실행)
- 실행/디버그:
- 상태 표시줄에서 실행/디버그할 타겟(예: hello_cmake, run_tests)을 선택합니다.
- Ctrl+F5 (실행) 또는 F5 (디버그) 키를 눌러 선택된 타겟을 실행하거나 디버깅할 수 있습니다.
- Test: 테스트 타겟(run_tests 같은)이 있고 CTest가 활성화된 경우, VS Code의 테스트 탐색기(Testing Explorer) 탭에서 테스트를 확인하고 실행할 수 있습니다.
CMake Tools를 사용하면 터미널 명령어를 직접 입력하는 대신 VS Code 내에서 클릭 몇 번으로 CMake 프로젝트를 관리하고 빌드/실행/디버그할 수 있어 매우 편리합니다.
CMake와 CMakeLists.txt는 처음 배울 때 다소 복잡하게 느껴질 수 있습니다. 하지만 왜 사용해야 하는지 이해하고, 기본적인 명령어와 구조를 파악하며, 간단한 예제부터 차근차근 따라 해보면 금방 익숙해질 수 있습니다.
반응형
'프로그램개발도구 > Cygwin' 카테고리의 다른 글
| [Cygwin]Windows에서 Linux처럼 C,C++개발! (0) | 2025.02.02 |
|---|