目前我有一个如下所示的目录结构
.
├── CMakeLists.txt
├── Base
│ ├── CMakeLists.txt
│ ├── include
│ │ └── base.h
│ └── src
│ └── base.cpp
├── Derived
│ ├── CMakeLists.txt
│ ├── include
│ │ └── derived.h
│ └── src
│ └── derived.cpp
└── src
└── main.cpp
和CMakeLists.txt文件看起来像
./CMakeLists.txt
cmake_minimum_required(VERSION 3.1)
set(CMAKE_CXX_STANDARD 11)
project(MyProj)
add_subdirectory(Base)
add_subdirectory(Derived)
add_executable(main src/main.cpp)
target_link_libraries(main Base)
target_link_libraries(main Derived)
./Base/CMakeLists.txt
add_library(Base STATIC src/base.cpp)
target_include_directories(Base PUBLIC include)
./Derived/CMakeLists.txt
add_library(Derived STATIC src/derived.cpp)
target_include_directories(Derived PUBLIC include)
target_link_libraries(Derived Base)
我想知道在C++中使用继承时,这是否是构建 CMake 项目的合适方法。如果有更惯用的方法来构建它,我愿意接受建议。
如果你的目的是构建两个库和一个可执行文件,那么这就是你的结构所实现的。但是,我建议您思考为什么要这样做,也许可以考虑将两个类放在一个库中是否更简单。
如果我继续扩展它,比如说创建另一个继承自派生的类,那么我必须创建一个新的 CMakeLists.txt 文件,然后针对这些文件链接并包含。我这样做没有问题,但对于大型项目来说似乎不太可维护
否,您不必创建新的 CMakeLists.txt除非您添加新目标。一个项目不一定需要多个目标。
目标(无论是可执行文件还是库(不限于只有一个翻译单元。
我个人对小项目的偏好是三个(或两个(目标:一个包含所有功能的库,一个主可执行文件,其int main()
除了调用库之外什么都不做(如果项目是可执行文件而不仅仅是库(,以及一个测试可执行文件,其中包含来自测试框架的int main()
。如果库具有可在其他项目中重用的部分,则可以选择将其拆分为较小的部分。
set(CMAKE_CXX_STANDARD 11)
更喜欢特定于目标的属性:
set_target_properties(
Base PROPERTIES
CXX_STANDARD 11
# use unless you also support older standards
CXX_STANDARD_REQUIRED ON
)
依赖项将继承该属性,但您可以在每个属性中显式设置它,以便在以后决定不使用基本库时减少损坏的可能性。
为每个类创建一个库是矫枉过正的,可能会减慢某些构建系统上的编译速度。
在我的一些项目中,我有超过 300 种类型,这还不包括模板和 lambda。我无法想象为每个类创建一个库。
我想知道在C++中使用继承时,这是否是构建 CMake 项目的合适方式
您正在使用的功能不应更改代码的物理组织方式。相反,将文件布局基于代码的逻辑自包含部分,每个部分之间有明确的依赖关系。
唯一的吹毛求疵:使用此表单将库链接在一起:
target_link_libraries(main PUBLIC Base) # or private
CMake 的其余部分充分利用了基于目标的 API。我唯一要改变的就是在构成库方面不那么细粒度。