ModernCppStarter 다운로드 -ModernCppStarter 소스 ModernCppStarter 다운로드

ModernCppStarter

C/C++

v0.18.0

다운로드

Moderncppstarter

새로운 C ++ 프로젝트를 설정하려면 일반적으로 테스트, 실행 파일 및 지속적인 통합을 갖춘 최신 C ++ 프로젝트의 경우 상당한 양의 준비 및 보일러 플레이트 코드가 필요합니다. 이 템플릿은 많은 이전 프로젝트의 학습 결과이며 최신 C ++ 프로젝트를 설정하는 데 필요한 작업을 줄이는 데 도움이됩니다.

특징

현대 CMAKE 관행
단일 헤더 라이브러리 및 모든 규모의 프로젝트에 적합
라이브러리 및 실행 가능한 코드의 깨끗한 분리
통합 테스트 스위트
GitHub 동작을 통한 지속적인 통합
Codecov를 통한 코드 적용 범위
clang-format 및 cmake-format을 통해 Format.cmake가 시행하는 코드 서식
CPM.CMAKE를 통한 재현 가능한 종속성 관리
PackageProject.cmake를 통한 자동 버전 설정 정보 및 헤더 생성이있는 설치 가능한 대상
Doxygen 및 Github 페이지를 사용한 자동 문서 및 배포
소독제 도구 등을 지원합니다

용법

템플릿을 필요에 맞게 조정하십시오

이 repo를 템플릿으로 사용하십시오.
관련 cmakelists.txt에서 "greeter"의 모든 발생을 프로젝트 이름으로 바꾸십시오.
- 대문자 문제 : Greeter 프로젝트 이름을 의미하고 greeter 파일 이름에 사용됩니다.
- 프로젝트의 소문자 이름을 사용하려면 include/greeter 디렉토리의 이름을 바꾸고 그에 따라 모든 관련 #include 를 업데이트하십시오.
소스 파일을 자신의 것으로 바꾸십시오
헤더 전용 라이브러리의 경우 : cmakelists.txt의 주석을 참조하십시오
CODECOV_TOKEN 의 프로젝트의 Github 비밀에 프로젝트의 Codecov 토큰 추가
행복한 코딩!

결국, 독립형 디렉토리 또는 프로젝트의 관련없는 GitHub 워크 플로와 같은 사용되지 않은 파일을 제거 할 수 있습니다. 라이센스를 프로젝트에 적합한 라이센스로 교체하십시오.

라이브러리와 하위 프로젝트 코드를 깨끗하게 분리하기 위해 OUTER CMakeList.txt 는 라이브러리 자체 만 정의하는 반면 테스트 및 기타 하위 프로젝트는 자체 디렉토리에 자체 포함됩니다. 개발 중에는 일반적으로 모든 하위 프로젝트를 한 번에 구축하는 것이 편리합니다.

독립형 대상을 빌드하고 실행하십시오

다음 명령을 사용하여 실행 가능 대상을 빌드하고 실행하십시오.

cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/Greeter --help

테스트 스위트를 구축하고 실행하십시오

프로젝트의 루트 디렉토리에서 다음 명령을 사용하여 테스트 스위트를 실행하십시오.

cmake -S test -B build/test
cmake --build build/test
CTEST_OUTPUT_ON_FAILURE=1 cmake --build build/test --target test

# or simply call the executable: 
./build/test/GreeterTests

코드 커버리지 정보를 수집하려면 -DENABLE_TEST_COVERAGE=1 옵션으로 cmake를 실행하십시오.

Clang- 형식을 실행하십시오

프로젝트의 루트 디렉토리의 다음 명령을 사용하여 C ++ 및 CMAKE 소스 스타일을 확인하고 수정하십시오. 이를 위해서는 Clang-format , cmake-format 및 pyyaml을 현재 시스템에 설치해야합니다.

cmake -S test -B build/test

# view changes
cmake --build build/test --target format

# apply changes
cmake --build build/test --target fix-format

자세한 내용은 format.cmake를 참조하십시오. 이러한 종속성은 PIP를 사용하여 쉽게 설치할 수 있습니다.

pip install clang-format==14.0.6 cmake_format==0.6.11 pyyaml

문서를 작성하십시오

문서는 GitHub 릴리스가 생성 될 때마다 자동으로 구축 및 게시됩니다. 문서를 수동으로 작성하려면 다음 명령을 호출하십시오.

cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.html

문서를 로컬에서 구축하려면 시스템에 Doxygen, Jinja2 및 Pygments가 설치되어야합니다.

한 번에 모든 것을 구축하십시오

이 프로젝트에는 또한 모든 대상을 동시에 구축 할 수있는 all 디렉토리도 포함되어 있습니다. 이것은 모든 하위 프로젝트를 IDE에 노출시키고 라이브러리의 중복 빌드를 피하기 때문에 개발 중에 유용합니다.

cmake -S all -B build
cmake --build build

# run tests
./build/test/GreeterTests
# format code
cmake --build build --target fix-format
# run standalone
./build/standalone/Greeter --help
# build docs
cmake --build build --target GenerateDocs

추가 도구

테스트 및 독립형 하위 프로젝트에는 CMAKE 구성 인수를 통해 주문형 추가 도구를 가져 오는 데 사용되는 도구가 포함되어 있습니다. 다음은 현재 지원됩니다.

소독제

정적 분석기

-DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck> 설정하여 정적 분석기를 활성화 할 수 있습니다 -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck> 또는 세미콜론으로 분리 된 인용 표시에 대한 조합. 기본적으로 분석기는 .clang-format 과 같은 구성 파일을 자동으로 찾습니다. CLANG_TIDY_ARGS , IWYU_ARGS 또는 CPPCHECK_ARGS 변수를 설정하여 추가 인수를 분석기에게 전달할 수 있습니다.

ccache

-DUSE_CCACHE=<ON | OFF> 로 구성하여 CCache를 활성화 할 수 있습니다 -DUSE_CCACHE=<ON | OFF> .

FAQ

헤더 전용 라이브러리에 이것을 사용할 수 있습니까?

예, Cmakelists.txt에 문서화 된대로 라이브러리 유형을 INTERFACE 라이브러리로 변경해야합니다. 템플릿을 기반으로 한 헤더 전용 라이브러리 예제는 여기를 참조하십시오.

독립형 목표 / 문서가 필요하지 않습니다. 어떻게 제거 할 수 있습니까?

독립형 / 문서 디렉토리와 GitHub 워크 플로우 파일에 따라 제거하십시오.

독립형 및 테스트를 동시에 구축 할 수 있습니까? / 모든 하위 프로젝트에 대해 IDE에게 어떻게 알 수 있습니까?

템플릿을 모듈화하기 위해 라이브러리에서 파생 된 모든 하위 프로젝트는 자체 CMAKE 모듈로 분리되었습니다. 이 접근법은 제 3 자 프로젝트가 프로젝트 라이브러리 코드를 재사용하는 것을 사소하게 만듭니다. IDE가 프로젝트의 전체 범위를 볼 수 있도록 템플릿에는 모든 하위 프로젝트에 대한 단일 빌드를 생성하는 all 디렉토리가 포함되어 있습니다. 이것을 최상의 IDE 지원을위한 기본 디렉토리로 사용하십시오.

cmakelists.txt에서 소스 파일을 추가하기 위해 GLOB 사용하고 있음을 알 수 있습니다. 그게 악하지 않나요?

소스 파일 구조의 변경 사항은 CMake의 빌더에 의해 자동으로 잡히지 않을 수 있으므로 Glob가 나쁜 것으로 간주되며 변경 사항에 대한 CMAKE를 수동으로 호출해야합니다. 나는 단순성을 위해 GLOB 솔루션을 개인적으로 선호하지만, 명시 적으로 나열된 출처로 변경하십시오.

내 라이브러리에 의존하는 추가 대상을 만들고 싶습니다. 주요 cmakelists를 포함하도록 수정해야합니까?

라이브러리 Cmakelists (C ++ 세계에서 일반적인 광경이지만)에서 파생 된 프로젝트를 포함시키지 마십시오. 이로 인해 의존성 트리를 효과적으로 역전시키고 빌드 시스템을 추론하기가 어렵습니다. 대신, 라이브러리를 종속성 (예 : 독립형 디렉토리와 같은)으로 추가하는 cmakelists와 함께 새 디렉토리 또는 프로젝트를 만듭니다. 유형에 따라이 구성 요소를 별도의 리포지토리로 옮기고 특정 커밋 또는 라이브러리 버전을 참조하십시오. 이는 개별 라이브러리와 구성 요소가 독립적으로 개선되고 업데이트 될 수 있다는 이점이 있습니다.

cpm.cmake를 사용하여 외부 종속성을 추가하는 것이 좋습니다. 이 라이브러리의 사용자가 CPM.CMAKE를 사용하도록 강요할까요?

CPM.CMAKE는 자체 포함 된 CMAKE 스크립트이므로 라이브러리 사용자에게는 보이지 않아야합니다. 문제가 발생하면 CMAKE 또는 ENV 변수 CPM_USE_LOCAL_PACKAGES 정의하여 사용자는 항상 옵트 아웃 할 수 있으며, 이는 모든 통화를 CPMAddPackage 에 대한 모든 호출을 find_package 호출로 무시합니다. 이를 통해 사용자는 VCPKG 또는 Conan과 같은 좋아하는 외부 C ++ 종속성 관리자와 함께 프로젝트를 사용할 수 있습니다.

오프라인으로 프로젝트를 구성하고 빌드 할 수 있습니까?

프로젝트 구축에는 인터넷 연결이 필요하지 않지만 CPM 누락 종속성을 사용할 때는 구성 시간에 다운로드됩니다. 중복 다운로드를 피하려면 CPM.CMAKE 캐시 디렉토리를 설정하는 것이 좋습니다. 예 : export CPM_SOURCE_CACHE=$HOME/.cache/CPM . 이렇게하면 얕은 클론이 가능하며 오프라인 구성 종속성을 이미 캐시에서 사용할 수 있습니다.