1. 소개
프로그램 개발 과정에서 라이브러리(동적 라이브러리 및 정적 라이브러리)가 자주 도입됩니다. 때로는 둘 중 하나만, 때로는 두 가지가 혼합되어 있습니다. 이 경우 프로젝트에서 라이브러리를 지원하는 방법에 대한 질문이 발생합니다(이는 라이브러리의 버전 관리를 포함하지 않습니다. 즉, DLL HELL과 같은 문제를 처리하지 않습니다). 이를 수행하는 방법에는 여러 가지가 있으며 플랫폼과 개발 도구에 따라 처리 방법이 다릅니다. 예를 들어 VS와 Idea의 차이가 있고 언어마다 다르게 처리할 수 있으며, 모두 실제 상황에 따라 개발자가 직접 처리해야 합니다.
여기서는 타사 라이브러리 관리를 위해 Linux에서 Cmake를 사용하는 몇 가지 방법만 언급합니다.
둘, 네 가지 형태
Linux에서 세 번째 라이브러리를 사용하는 방법은 Cmake를 사용하여 빌드 및 관리하는 경우 주로 다음과 같습니다.
1. 직접 컴파일 및 컴파일
가장 일반적으로 사용되는 방법이며 개발자가 사용했습니다. 그것을 사용하는 오래된 방법은 일반적으로 다음과 같습니다.
mkdir build
cd build
cmake ..
make -j5
make install
그러나 상위 버전의 CMake는 다음과 같은 간단한 방법을 지원합니다.
cmake -B build -DCMAKE_PREFIX_PATH=/home/fpc/Qt65/6.5.0/gcc_64 （通过 -S 可以 指定编译路径 -G指定构造方式 如Ninja）
cmake --build build -j5（--parallel 5）
스테이션 B의 큰 형님은 이 현대적인 CMake라고 불렀습니다.
이 방법은 초보자나 프로젝트 관리가 간단한 곳에 더 적합합니다. 이해하기 쉽고 조작이 쉽다는 장점이 있고 단점은 프로젝트의 CMake 파일에서 라이브러리의 컴파일과 링크를 수동으로 제어하고 관리해야 한다는 점입니다. 다음과 유사합니다.
find_package (库名称 1.6.0 REQUIRED)
add_executable (myapp main.cpp)
target_link_libraries (myapp 库名称)
버전이나 머신이 다른 개발 환경이 있는 경우 팀이 협력할 때 예기치 않은 문제가 발생할 수 있습니다. 이러한 종류의 문제의 특징은 무작위적이고 찾기가 쉽지 않기 때문에 이 방법을 약간 더 큰 프로젝트에 채택할 경우 엄격한 라이브러리 버전 관리 및 종속성 관리 지침이 있어야 합니다. 그러나 사람들에게 의존하는 것이 종종 신뢰할 수 없다는 것을 모두가 이해합니다.
2. CMake는 git 하위 모듈 하위 모듈 제어와 협력합니다.
이 방식은 팀간 소스코드 수준에서 효과적인 관리에 적합하며, 라이브러리만 제공하는 타사에는 적합하지 않습니다. 특정 프로젝트에 적용되므로 주의를 기울이십시오. 적절한 경로를 사용하십시오.
增加子模块：
cd examples
git submodule add http://xxx.xxx/libname.git
下载子模块：
git clone --recursive git@xxxxxx/parent_libname.git
或者没有使用 --recursive 下载完成后，进入子目录执行：
git submodule update --init
그런 다음 프로젝트의 전체 CMakeLists.txt 파일에 다음을 추가합니다.
add_subdirectory(${CMAKE_SOURCE_DIR}/examples/libname)
애플리케이션 타사 라이브러리의 프로젝트 CMakeLists.txt에 추가합니다.
add_dependencies(SUPRA_Lib libname)
TARGET_INCLUDE_DIRECTORIES(SUPRA_Lib
PUBLIC ${SUPRA_Lib_INCLUDEDIRS} libname_include
)
target_link_libraries(SUPRA_Lib ${SUPRA_Lib_LIBRARIES} libname_path)
이러한 방식으로 라이브러리는 외부 영향 없이 단단히 바인딩될 수 있습니다. 손쉬운 제어를 위한 소스 레벨 관리. 단점도 분명한데, 외부 라이브러리가 많아 업그레이드가 번거롭고 동시에 사용하는 모든 프로젝트에 위의 종속 프로젝트를 추가해야 한다는 점입니다.
3. 프로젝트 하위 디렉토리에 직접 추가
위와 다른 점은 이 타사 라이브러리가 실제로 특정 프로젝트의 하위 디렉토리가 되어야 한다는 것입니다. 즉, add_subdirectory는 Google과 같은 특정 프로젝트의 CMakeLists.txt 아래에 있습니다. glog는 다음과 같은 방법을 제공합니다.
add_subdirectory(${CMAKE_SOURCE_DIR}/examples/libname)
target_link_libraries(firt libname)
매우 간단하고 제한이 없으며 직접 사용할 수 있으며 헤더 파일과 add_dependencies, find_package 등을 처리할 필요가 없습니다. 단점은 모듈로 나누는 것만큼 명확하지 않을 수 있고, 대규모 프로젝트는 유지보수가 다소 불편할 수 있다는 점입니다.
4. 외부 프로젝트 사용 방법
이 방법의 자세한 사용 방법은 CMake 설명서를 참조하십시오.
include(ExternalProject)
SET(NodeEditor_DIR "${CMAKE_CURRENT_BINARY_DIR}/NodeEditor")
SET(NodeEditor_GIT_REPOSITORY "https://github.com/goeblr/nodeeditor.git" CACHE STRING "")
SET(NodeEditor_GIT_TAG "3bcba3740d68932f3ffaa4b3dc73e624fe51e2db" CACHE STRING "")
ExternalProject_Add(
NodeEditor
PREFIX "${NodeEditor_DIR}"
LOG_DOWNLOAD TRUE
LOG_UPDATE TRUE
LOG_CONFIGURE TRUE
LOG_BUILD TRUE
LOG_INSTALL TRUE
SOURCE_DIR "${NodeEditor_DIR}"
BINARY_DIR "${NodeEditor_DIR}_build"
STAMP_DIR "${NodeEditor_DIR}_stamp"
TMP_DIR "${NodeEditor_DIR}_tmp"
#--Download step--------------
GIT_REPOSITORY ${NodeEditor_GIT_REPOSITORY}
GIT_TAG ${NodeEditor_GIT_TAG}
#--Configure step-------------
CMAKE_ARGS
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY:PATH=${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY:PATH=${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}
-DCMAKE_BUILD_TYPE=Release
-DBUILD_EXAMPLES=OFF
-DQt5_DIR=${Qt5_DIR}
-DCMAKE_INSTALL_PREFIX=${NodeEditor_DIR}_install
-DNODE_EDITOR_STATIC=
#--Build step-----------------
#BUILD_ALWAYS 0
#--Install step-----------------
INSTALL_DIR=${NodeEditor_DIR}_install
)
SET(NodeEditor_LIBRARIES "nodes")
INCLUDE_DIRECTORIES(SUPRA_GUI "${NodeEditor_DIR}_install/include")
LINK_DIRECTORIES(SUPRA_GUI "${NodeEditor_DIR}_install/lib")
그런 다음 여전히 현재 프로젝트에서:
TARGET_LINK_LIBRARIES(SUPRA_GUI
${NodeEditor_LIBRARIES})
add_dependencies(SUPRA_GUI SUPRA_Lib NodeEditor)
이 방식은 단순하지는 않으나 응용에 유연하여 사용할 수 있는 코드라면 어떤 것이라도 운용이 가능하다고 할 수 있다. 단점도 뻔하고, 복잡하고, 컴파일과 상관없는 부분을 많이 다루어야 합니다.
3. 요약
현재 CMake는 C++ 엔지니어링 애플리케이션의 주류 모드여야 합니다. 그것을 사용하는 장점은 MakeFile을 작성하는 것보다 훨씬 간단하고 개발자가 이해하기 더 적합하며 비교적 간단합니다. 단점은 매크로 정의가 너무 많고 다양한 오류가 이해하기 쉽지 않다는 것입니다. 이상한 문제가 발생하면 베테랑이 울어야 할 수도 있습니다. 결함을 숨기지 않고 열심히 공부하고 더 많이 사용하고 일부 함정을 피하기 위해 주도권을 잡으면 CMake가 여전히 매우 좋은 도구임을 알게 될 것입니다.