CMake中的链接权限详解:深入理解PRIVATE、PUBLIC与INTERFACE

1. 简介 (Introduction)

在我们的日常编程生涯中,构建系统是一个不可或缺的部分。它们负责将源代码转化为可执行的程序。而在众多的构建系统中,CMake无疑是最受欢迎的一个。但为什么CMake如此受欢迎呢?这背后的原因,与人类对于秩序和结构的渴望息息相关。

1.1 CMake的重要性

CMake是一个跨平台的构建系统,它允许开发者使用一种简单的语法来描述项目的构建过程,然后生成对应平台的构建文件。这种跨平台的特性,使得开发者可以在不同的操作系统和编译器上,使用同一套CMake文件来构建他们的项目。

但更为重要的是,CMake为我们提供了一种结构化的方式来描述项目的构建过程。这种结构化的描述,不仅使得构建过程更加清晰和可维护,而且也为我们提供了一种方式,来理解和掌握复杂的项目结构。

正如《人类简史》中所说:"人类的力量,来源于我们的能力,去创造并相信故事。"(Yuval Noah Harari, "Sapiens: A Brief History of Humankind")。CMake的语法和结构,为我们提供了一种"故事",帮助我们理解和掌握项目的构建过程。

1.2 链接权限的基本概念

在CMake中,链接权限是一个核心的概念。它决定了库在何时被链接到目标上。简单来说,链接权限就是一个规则,告诉CMake如何处理库和目标之间的关系。

为了更好地理解链接权限,我们可以将其比喻为人类社会中的关系。例如,PRIVATE权限可以看作是亲密的朋友或家人之间的关系,只有当你直接与他们互动时,你才会受到他们的影响。而PUBLIC权限则可以看作是公众人物或名人,他们不仅会影响到与他们直接互动的人,还会影响到那些通过其他途径了解他们的人。

这种比喻,不仅帮助我们理解链接权限的工作原理,而且也为我们提供了一种方式,来理解人类社会中复杂的关系网络。

cmake 复制代码
# 代码示例:使用PRIVATE权限链接库
target_link_libraries(my_target PRIVATE some_library)

在上面的代码示例中,我们使用PRIVATE权限,将some_library库链接到my_target目标上。这意味着,只有当my_target被构建时,some_library库才会被链接。

正如庄子在其著作中所说:"天地与我并生,而万物与我为一。"(Zhuangzi, "The Complete Works of Zhuangzi")。这句话告诉我们,万物都是相互联系的,而链接权限则是CMake中描述这种联系的方式。

2. CMake中的链接权限

2.1 为什么需要链接权限?

在编程的世界中,我们经常需要将多个代码模块或库组合在一起,以构建更大、更复杂的系统。这就像是拼图,每个库或模块都是拼图的一块。但是,不是所有的拼图块都需要与其他块紧密相连。有时,我们只需要某些块在内部相互连接,而不需要与外部的块连接。这就是CMake链接权限的来源。

正如《人性的弱点》中所说:"人们更容易接受他们自己想要的东西。"(Dale Carnegie, "How to Win Friends and Influence People")。在编程中,我们希望能够精确地控制哪些库与其他库或应用程序链接,以确保系统的稳定性和可维护性。

2.2 链接权限的基本定义

在CMake中,链接权限决定了库在何时被链接到目标上。主要有三种权限:

  • PRIVATE (私有): 当目标自身需要此链接库时使用。
  • PUBLIC (公共): 当目标自身或其他目标链接了这个目标时使用。
  • INTERFACE (接口): 当目标自身不需要此链接库,但其他目标链接了这个目标时使用。
cmake 复制代码
# 示例代码
target_link_libraries(target PRIVATE lib1)
target_link_libraries(target PUBLIC lib2)
target_link_libraries(target INTERFACE lib3)

这三种权限的存在,使得我们可以更加灵活地管理项目的依赖关系,确保每个目标只链接它真正需要的库。

从更深层次的角度看,这种权限管理反映了人类对事物的分类和组织的天性。正如庄子在《庄子·内篇》中所说:"天地之大德曰生,圣人之大宝曰位。"这意味着每个事物都有其固有的位置和角色。在编程中,通过链接权限,我们为每个库和目标定义了其位置和角色,确保系统的和谐运作。

2.3 权限的深入解析

为了更好地理解这三种权限,我们可以从以下几个角度进行分析:

权限 定义 使用场景 与其他权限的比较
PRIVATE 只有目标自身需要此链接库时使用。 静态库内部依赖,不希望外部继承的依赖。 不会被其他目标继承。
PUBLIC 目标自身或其他目标链接了这个目标时使用。 共享库的公共依赖,或者希望被其他目标继承的依赖。 会被其他目标继承。
INTERFACE 目标自身不需要此链接库,但其他目标链接了这个目标时使用。 头文件库,或者只希望传递依赖而不实际链接的情况。 只会被其他目标继承。

这种分类和组织的方式,再次体现了人类对事物的分类和组织的天性。我们总是试图为事物找到其固有的位置和角色,以确保整体的和谐和秩序。

  1. PRIVATE:

    • 当目标自身需要此链接库时使用。
    • 如果其他目标链接了这个目标,它们不会继承这个链接库。
    • 对于静态库,这意味着当目标被构建时,私有依赖项会被链接。
    • 对于共享库和可执行文件,这意味着当它们被构建时,私有依赖项会被链接。

    示例:

    cmake 复制代码
    target_link_libraries(my_target PRIVATE some_library)
  2. PUBLIC:

    • 当目标自身需要此链接库,或者其他目标链接了这个目标时使用。
    • 其他目标链接这个目标时,它们会继承这个链接库。
    • 对于静态库,这意味着当目标被构建或者其他目标链接了这个目标时,公共依赖项会被链接。
    • 对于共享库和可执行文件,这意味着当它们被构建或者其他目标链接了这个目标时,公共依赖项会被链接。

    示例:

    cmake 复制代码
    target_link_libraries(my_target PUBLIC another_library)
  3. INTERFACE:

    • 当目标自身不需要此链接库,但其他目标链接了这个目标时使用。
    • 其他目标链接这个目标时,它们会继承这个链接库,但目标自身不会链接这个库。
    • 这主要用于头文件只的库或者当你只想传递链接依赖而不实际链接它们时。

    示例:

    cmake 复制代码
    target_link_libraries(my_target INTERFACE yet_another_library)

这三种权限也适用于target_include_directoriestarget_compile_definitions等命令,决定了目标或其消费者如何继承这些属性。

3. PRIVATE权限详解

3.1 定义与用途

在CMake中,PRIVATE权限是我们在链接库时经常会遇到的一个关键词。简而言之,当我们说一个库是以PRIVATE方式链接的,我们意味着这个库只对当前目标有意义,而不会被传递给其他链接了此目标的目标。

考虑一个日常生活中的例子。当我们为自己买一件衣服时,这件衣服只属于我们,我们的朋友不能因为与我们交往就自动拥有这件衣服。这与PRIVATE权限的概念相似。衣服(库)是私有的,只属于我们(目标)。

cmake 复制代码
target_link_libraries(my_target PRIVATE some_library)

在上述代码中,some_library只会链接到my_target,而不会传递给其他链接了my_target的目标。

3.2 实际应用场景

假设我们正在构建一个项目,其中有一个静态库libA和一个可执行文件exeBlibA需要一个第三方库libThirdParty来完成某些功能,但这个功能只在libA内部使用,exeB并不直接依赖于它。

在这种情况下,我们应该使用PRIVATE权限来链接libThirdPartylibA,因为exeB不需要知道或链接到libThirdParty

cmake 复制代码
target_link_libraries(libA PRIVATE libThirdParty)

这样,libThirdParty只会链接到libA,而不会影响到exeB或其他可能链接到libA的目标。

3.3 与其他权限的比较

为了更好地理解PRIVATE权限,我们可以将其与其他两种权限进行比较。

权限/特性 PRIVATE PUBLIC INTERFACE
目标自身使用
传递给其他目标
目标自身不使用但传递

从上表中,我们可以看到PRIVATE权限是唯一一个不会传递给其他目标的权限。这使得PRIVATE在某些情况下非常有用,例如当我们不希望某个库被其他目标知晓或链接时。

正如庄子在《逍遥游》中所说:"天下之达道者,共怀宇宙,式万物为一。"在编程中,我们也应该追求这种"一"的状态,即明确每个组件的职责和边界,使整个系统更加和谐和高效。

4. PUBLIC权限详解 (Diving into PUBLIC)

4.1 定义与用途 (Definition and Usage)

在CMake中,PUBLIC权限是一个非常有用的工具,它允许我们在目标自身和其他链接到该目标的项目中都使用某个库。这意味着,当我们声明一个库为PUBLIC依赖时,不仅当前目标可以访问该库,而且任何链接到当前目标的其他目标也可以访问它。

cmake 复制代码
target_link_libraries(my_target PUBLIC another_library)

在上面的代码中,my_target不仅可以使用another_library,而且任何链接到my_target的其他目标也可以使用它。

正如《思考,快与慢》中所说:"我们过于依赖第一印象,往往忽略了深入的分析。"(Daniel Kahneman)。在编程中,我们可能会因为对某个工具或命令的第一印象而忽略其深层的功能和用途。但是,深入理解PUBLIC权限可以帮助我们更有效地管理项目的依赖关系。

4.2 实际应用场景 (Practical Use Cases)

考虑一个常见的场景:你正在开发一个库,这个库依赖于其他几个库。当其他项目使用你的库时,它们也需要这些依赖。在这种情况下,使用PUBLIC权限可以确保这些依赖被正确地传递。

例如,你有一个数学库math_lib,它依赖于matrix_libvector_lib。当其他项目使用math_lib时,它们也需要matrix_libvector_lib。这时,你可以这样设置:

cmake 复制代码
target_link_libraries(math_lib PUBLIC matrix_lib vector_lib)

这样,任何链接到math_lib的项目都会自动获得对matrix_libvector_lib的访问权限。

这种方法的优雅之处在于,它避免了冗余和重复。正如《道德经》中所说:"知者不言,言者不知。"(老子)。在编程中,简洁和明确是至关重要的,而PUBLIC权限为我们提供了一个简洁的方法来管理复杂的依赖关系。

4.3 与其他权限的比较 (Comparison with Other Permissions)

为了更好地理解PUBLIC权限,我们可以将其与PRIVATEINTERFACE权限进行比较。

权限 目标自身是否链接 其他链接到目标的是否链接 最佳用途
PRIVATE 当目标自身需要库,但其他链接到目标的不需要时
PUBLIC 当目标自身和其他链接到目标的都需要库时
INTERFACE 当目标自身不需要库,但其他链接到目标的需要时

从上表可以看出,PUBLIC权限是这三种权限中最具包容性的。它确保了库在多个场景中都可以被访问,从而提供了更大的灵活性。

在选择权限时,我们应该考虑到项目的实际需求和未来的可扩展性。正如《存在与时间》中所说:"人是他自己的未来。"(Martin Heidegger)。在编程中,我们的选择不仅影响当前的项目,还会影响项目的未来发展和扩展。

5. INTERFACE权限详解 (Diving into INTERFACE)

5.1 定义与用途 (Definition and Usage)

INTERFACE在CMake中是一个相当特殊的权限。它不是为目标自身定义的,而是为了定义与其他目标之间的关系。简而言之,当你为一个目标设置INTERFACE权限,你实际上是在告诉CMake:"当其他目标链接到我时,它们需要这些设置,但我自己不需要。"(In CMake, the INTERFACE keyword essentially tells: "When other targets link to me, they need these settings, but I myself don't.")

这种权限在头文件只的库中尤其有用,因为它们本身不需要编译或链接任何东西,但使用它们的目标可能需要知道头文件的位置。

5.2 实际应用场景 (Practical Use Cases)

考虑一个常见的场景:你有一个只包含头文件的库,例如模板库。这个库本身并不生成任何二进制文件,但它可能有一些公共头文件,需要被其他库或应用程序所知道。

cmake 复制代码
add_library(header_only_lib INTERFACE)
target_include_directories(header_only_lib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)

在上述代码中,我们定义了一个INTERFACE库,并告诉CMake其他链接到此库的目标需要知道头文件的位置。

正如《编程的艺术》中所说:"代码是写给人看的,顺便给机器执行。"("Code is written for humans to read, and only incidentally for machines to execute.") 这里的INTERFACE权限也是如此,它更多地是为了帮助开发者理解和组织代码,而不仅仅是为了满足编译器的需求。

5.3 与其他权限的比较 (Comparison with Other Permissions)

为了更好地理解INTERFACE权限,我们可以与其他两种权限进行对比:

权限 (Permission) 目标自身 (For the Target Itself) 链接到目标的其他目标 (For Targets Linking to It)
PRIVATE 需要 (Required) 不需要 (Not Required)
PUBLIC 需要 (Required) 需要 (Required)
INTERFACE 不需要 (Not Required) 需要 (Required)

从上表可以看出,INTERFACE权限与其他权限的主要区别在于它不为目标自身定义任何东西,只为其他链接到它的目标定义。

人类的思维方式往往是基于对比和关系的。正如《思考的乐趣》中所说:"我们通过对比来理解,通过关系来记忆。"("We understand by comparing, and we remember by relating.") 这也是为什么我们经常使用表格、图表和示例来解释和学习新的概念。

5.4 INTERFACE在实际代码中的应用 (Applying INTERFACE in Real Code)

考虑以下C++代码,它是一个简单的模板函数库:

cpp 复制代码
// math_utils.h
#pragma once

template <typename T>
T add(T a, T b) {
    return a + b;
}

为了在CMake中正确地引用这个头文件库,我们可以使用INTERFACE权限:

cmake 复制代码
add_library(math_utils INTERFACE)
target_include_directories(math_utils INTERFACE ${CMAKE_CURRENT_SOURCE_DIR})

这样,任何链接到math_utils的目标都会知道这个头文件的位置,但math_utils本身不会生成任何二进制文件。

这种方式的设计精妙之处在于,它允许开发者更加自然地组织和管理代码,而不是被迫将所有东西都放入一个巨大的二进制文件中。这也反映了编程中的"关注点分离"原则,即每个部分都应该只关心自己的任务,而不是整个系统的所有细节。

6. 权限在其他命令中的应用 (Permissions in Other Commands)

6.1 target_include_directories中的权限

在CMake中,我们不仅可以为目标设置链接库,还可以设置包含目录。这些目录通常包含头文件,它们是编译源代码时所需的。target_include_directories命令允许我们为目标设置这些目录,并且我们可以为这些目录设置权限。

例如,假设我们有一个库my_library,它的头文件位于include/目录下:

cmake 复制代码
target_include_directories(my_library PUBLIC include/)

在这里,我们使用了PUBLIC权限,这意味着任何链接到my_library的目标都会自动获得这个包含目录。

正如庄子所说:"道生一,一生二,二生三,三生万物。"(来源:《庄子》)在这里,"道"可以看作是我们的项目结构,而"一"、"二"、"三"则代表了我们的目标、链接库和包含目录。它们共同构成了项目的基础,而权限则决定了它们之间的关系。

6.2 target_compile_definitions中的权限

除了包含目录,我们还经常需要为目标设置编译定义。这些定义通常用于条件编译,例如,根据不同的平台或配置设置不同的编译选项。target_compile_definitions命令允许我们为目标设置这些定义,并且我们也可以为这些定义设置权限。

考虑以下示例:

cmake 复制代码
target_compile_definitions(my_app PRIVATE DEBUG_MODE=1)

在这里,我们为my_app目标设置了一个私有定义DEBUG_MODE。由于使用了PRIVATE权限,这意味着只有my_app会看到这个定义,而链接到my_app的其他目标则不会。

正如孟子所说:"人之所以能,是相信能。"(来源:《孟子》)在编程中,我们通过定义来告诉编译器我们"相信"某些条件是真的,从而影响代码的行为。

6.3 其他相关命令

除了上述命令,CMake还提供了其他一些命令,如target_sourcestarget_compile_options等,它们也支持权限设置。这些命令允许我们为目标设置源文件、编译选项等,并为它们设置相应的权限。

例如,我们可以为目标添加额外的源文件:

cmake 复制代码
target_sources(my_app PRIVATE extra_source.cpp)

在这里,我们为my_app添加了一个额外的源文件extra_source.cpp,并使用了PRIVATE权限。

这些命令和权限的组合为我们提供了强大的工具,帮助我们更好地组织和管理项目。正如庄子所说:"天下之达道者,共为一术。"(来源:《庄子》)在CMake中,这些命令和权限就是那"一术",它们共同构成了项目管理的艺术。

7. 权限选择的最佳实践

7.1 如何决定使用哪种权限?

在CMake中,选择链接权限往往取决于你的目标和库之间的关系。但是,这并不仅仅是一个技术决策。从更深层次上看,这也涉及到对项目结构和维护性的思考。

正如《设计模式》(Design Patterns)中所说:"每个模式描述了一个在我们周围不断重复出现的问题,以及该问题的核心解决方案。"在CMake的上下文中,选择链接权限也是一个模式,我们需要根据实际情况选择合适的解决方案。

  • PRIVATE: 当你的目标需要库,但不希望其他链接到你的目标的库或可执行文件继承这个库时,选择PRIVATE。它反映了一个明确的意图:这个库只是为当前目标服务的。

  • PUBLIC: 当你的目标和其他链接到你的目标的库或可执行文件都需要这个库时,选择PUBLIC。这意味着这个库是公共的依赖项,其他目标也可能需要它。

  • INTERFACE: 当你的目标本身不需要链接库,但其他链接到你的目标的库或可执行文件需要它时,选择INTERFACE。这通常用于头文件只的库或者当你只想传递链接依赖而不实际链接它们时。

7.2 常见的权限使用错误及其修正

7.2.1 使用PUBLIC代替PRIVATE

这是一个常见的错误,尤其是当开发者不确定是否应该公开某个库时。但是,过度使用PUBLIC可能会导致不必要的依赖关系,增加项目的复杂性。

示例:

cmake 复制代码
target_link_libraries(my_target PUBLIC unnecessary_library)

修正方法 : 如果unnecessary_library只是为my_target服务的,那么应该使用PRIVATE。

cmake 复制代码
target_link_libraries(my_target PRIVATE unnecessary_library)

7.2.2 忽略INTERFACE

很多开发者在使用CMake时,可能会完全忽略INTERFACE权限,因为它的用途不太明显。但是,当你有一个只包含头文件的库或者想要传递链接依赖而不实际链接时,INTERFACE是非常有用的。

示例:

cmake 复制代码
add_library(header_only_library INTERFACE)

这里,header_only_library只是一个接口库,不包含任何源文件,但可以包含头文件。

正如庄子在《逍遥游》中所说:"天地与我并生,而万物与我为一。"在编程的世界中,每一个选择都与整个项目的结构和未来的可维护性息息相关。选择正确的链接权限不仅可以使项目结构更加清晰,还可以避免未来的维护困难。

在选择链接权限时,我们不仅要考虑技术层面的问题,还要考虑项目的长远发展。选择合适的权限可以使项目更加健壮,更容易维护,也更容易理解。

8. 结论 (Conclusion)

8.1 链接权限的重要性回顾

在我们深入探讨CMake的链接权限之后,我们可以认识到这些权限不仅仅是技术上的实现细节。它们反映了软件设计中的一种哲学:如何将复杂的系统分解为可管理的、独立的部分,并确保它们之间的交互是有意义和有序的。

正如庄子在《庄子·逍遥游》中所说:"天地与我并生,而万物与我为一。"这句话虽然出自古老的哲学著作,但它与我们现代的软件设计有着惊人的相似之处。在软件中,各个组件(如库、模块或函数)与整个系统共同存在,并共同工作,形成一个有机的整体。

8.2 链接权限与人的思维方式

当我们选择使用PRIVATEPUBLICINTERFACE这些权限时,实际上是在决定如何将信息和功能从一个组件传递到另一个组件。这与人类如何在思考问题时从一个概念转移到另一个概念非常相似。

例如,当我们思考一个问题时,我们可能会从一个核心概念开始,然后逐渐扩展到相关的概念。这与使用PUBLIC权限的方式相似,因为它允许一个组件与其他组件共享其依赖关系。

另一方面,有时我们可能希望保持某些思考或知识为私有,不与他人分享。这与使用PRIVATE权限的方式相似,因为它限制了组件之间的信息流。

正如孟子在《孟子·滕文公上》中所说:"人之所以异于禽兽,是人有心也。"这里的"心"可以理解为人的思维和情感。在软件设计中,我们的选择也是基于我们的思维和对问题的理解。

8.3 为未来铺路

在探索CMake的链接权限时,我们不仅学到了技术知识,还学到了如何更好地组织和设计软件。这些知识和经验将为我们未来的软件项目铺路,帮助我们更好地理解和应对各种挑战。

正如《论语·为政》中所说:"学而时习之,不亦说乎?"通过不断地学习和实践,我们可以不断进步,找到更好的方法来解决问题。

在这个过程中,我们不仅仅是在学习技术,更是在学习如何思考,如何看待世界,以及如何与他人合作。这是一个永无止境的旅程,但它充满了乐趣和挑战。

希望这篇文章能为你提供一些启示,帮助你更好地理解CMake的链接权限,以及它们背后的哲学和思考方式。

相关推荐
开心工作室_kaic13 分钟前
ssm068海鲜自助餐厅系统+vue(论文+源码)_kaic
前端·javascript·vue.js
有梦想的刺儿32 分钟前
webWorker基本用法
前端·javascript·vue.js
cy玩具1 小时前
点击评论详情,跳到评论页面,携带对象参数写法:
前端
qq_390161772 小时前
防抖函数--应用场景及示例
前端·javascript
John.liu_Test2 小时前
js下载excel示例demo
前端·javascript·excel
Yaml42 小时前
智能化健身房管理:Spring Boot与Vue的创新解决方案
前端·spring boot·后端·mysql·vue·健身房管理
PleaSure乐事2 小时前
【React.js】AntDesignPro左侧菜单栏栏目名称不显示的解决方案
前端·javascript·react.js·前端框架·webstorm·antdesignpro
哟哟耶耶2 小时前
js-将JavaScript对象或值转换为JSON字符串 JSON.stringify(this.SelectDataListCourse)
前端·javascript·json
getaxiosluo2 小时前
react jsx基本语法,脚手架,父子传参,refs等详解
前端·vue.js·react.js·前端框架·hook·jsx
理想不理想v2 小时前
vue种ref跟reactive的区别?
前端·javascript·vue.js·webpack·前端框架·node.js·ecmascript