SET_TARGET_PROPERTIES(target1 target2 ...
PROPERTIES prop1 value1
prop2 value2 ...)
这条指令可以用来设置输出的名称,对于动态库,还可以用来指定动态库版本和 API 版本。
在本例中,我们需要作的是向 lib/CMakeLists.txt 中添加一条:
SET_TARGET_PROPERTIES(hello_static PROPERTIES OUTPUT_NAME
"hello")
这样,我们就可以同时得到 libhello.so/libhello.a 两个库了。
与他对应的指令是:
GET_TARGET_PROPERTY(VAR target property)
具体用法如下例,我们向 lib/CMakeListst.txt 中添加:
GET_TARGET_PROPERTY(OUTPUT_VALUE hello_static OUTPUT_NAME)
MESSAGE(STATUS “This is the hello_static
OUTPUT_NAME:”${OUTPUT_VALUE})
如果没有这个属性定义,则返回 NOTFOUND.
让我们来检查一下最终的构建结果,我们发现,libhello.a 已经构建完成,位于
build/lib 目录中,但是 libhello.so 去消失了。这个问题的原因是:cmake 在构建一
个新的 target 时,会尝试清理掉其他使用这个名字的库,因为,在构建 libhello.a 时,
就会清理掉 libhello.so.
为了回避这个问题,比如再次使用 SET_TARGET_PROPERTIES 定义
CLEAN_DIRECT_OUTPUT 属性。
向 lib/CMakeLists.txt 中添加:
SET_TARGET_PROPERTIES(hello PROPERTIES CLEAN_DIRECT_OUTPUT 1)
SET_TARGET_PROPERTIES(hello_static PROPERTIES
CLEAN_DIRECT_OUTPUT
1)
这时候,我们再次进行构建,会发现 build/lib 目录中同时生成了 libhello.so 和
libhello.a
五,动态库版本号
按照规则,动态库是应该包含一个版本号的,我们可以看一下系统的动态库,一般情况是
libhello.so.1.2
libhello.so ->libhello.so.1
libhello.so.1->libhello.so.1.2
为了实现动态库版本号,我们仍然需要使用 SET_TARGET_PROPERTIES 指令。
具体使用方法如下:
SET_TARGET_PROPERTIES(hello PROPERTIES VERSION 1.2 SOVERSION
1)
VERSION 指代动态库版本,SOVERSION 指代 API 版本。
将上述指令加入 lib/CMakeLists.txt 中,重新构建看看结果。
在 build/lib 目录会生成:
libhello.so.1.2
libhello.so.1->libhello.so.1.2
libhello.so ->libhello.so.1
六,安装共享库和头文件
以上面的例子,我们需要将 libhello.a, libhello.so.x 以及 hello.h 安装到系统目
录,才能真正让其他人开发使用,在本例中我们将 hello
的共享库安装到
/lib
目录,将 hello.h
安装到/include/hello 目录。
利用上一节了解到的 INSTALL 指令,我们向 lib/CMakeLists.txt 中添加如下指令:
INSTALL(TARGETS hello hello_static
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
INSTALL(FILES hello.h DESTINATION include/hello)
注意,静态库要使用 ARCHIVE 关键字
通过:
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make
make install
我们就可以将头文件和共享库安装到系统目录/usr/lib 和/usr/include/hello 中了。
七,小结:
本小节,我们谈到了:
如何通过 ADD_LIBRARY 指令构建动态库和静态库。
如何通过 SET_TARGET_PROPERTIES 同时构建同名的动态库和静态库。
如何通过 SET_TARGET_PROPERTIES 控制动态库版本
最终使用上一节谈到的 INSTALL 指令来安装头文件和动态、静态库。
在下一节,我们需要编写另一个高级一点的 Hello World 来演示怎么使用我们已经构建的
构建的共享库 libhello 和外部头文件。
六,如何使用外部共享库和头文件
抱歉,本节仍然继续折腾 Hello World.
上一节我们已经完成了 libhello 动态库的构建以及安装,本节我们的任务很简单:
编写一个程序使用我们上一节构建的共享库。
1,准备工作:
请在/backup/cmake 目录建立 t4 目录,本节所有资源将存储在 t4 目录。
2,重复以前的步骤,建立 src 目录,编写源文件 main.c,内容如下:
#include
int main()
{
HelloFunc();
return 0;
}
编写工程主文件 CMakeLists.txt
PROJECT(NEWHELLO)
ADD_SUBDIRECTORY(src)
编写 src/CMakeLists.txt
ADD_EXECUTABLE(main main.c)
上述工作已经严格按照我们前面季节提到的内容完成了。
3,外部构建
按照习惯,仍然建立 build 目录,使用 cmake ..方式构建。
过程:
cmake ..
make
构建失败,如果需要查看细节,可以使用第一节提到的方法
make VERBOSE=1 来构建
错误输出为是:
/backup/cmake/t4/src/main.c:1:19: error: hello.h: 没有那个文件或目录
4,引入头文件搜索路径。
hello.h 位于/usr/include/hello 目录中,并没有位于系统标准的头文件路径,
(有人会说了,白痴啊,你就不会 include
,同志,要这么干,我这
一节就没什么可写了,只能选择一个 glib 或者 libX11 来写了,这些代码写出来很多同志
是看不懂的)
为了让我们的工程能够找到 hello.h 头文件,我们需要引入一个新的指令
INCLUDE_DIRECTORIES,其完整语法为:
INCLUDE_DIRECTORIES([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)
这条指令可以用来向工程添加多个特定的头文件搜索路径,路径之间用空格分割,如果路径
中包含了空格,可以使用双引号将它括起来,默认的行为是追加到当前的头文件搜索路径的
后面,你可以通过两种方式来进行控制搜索路径添加的方式:
1,CMAKE_INCLUDE_DIRECTORIES_BEFORE,通过 SET 这个 cmake 变量为 on,可以
将添加的头文件搜索路径放在已有路径的前面。
2,通过 AFTER 或者 BEFORE 参数,也可以控制是追加还是置前。
现在我们在 src/CMakeLists.txt 中添加一个头文件搜索路径,方式很简单,加入:
INCLUDE_DIRECTORIES(/usr/include/hello)
进入 build 目录,重新进行构建,这是找不到 hello.h 的错误已经消失,但是出现了一个
新的错误:
main.c:(.text+0x12): undefined reference to `HelloFunc'
因为我们并没有 link 到共享库 libhello 上。
5,为 target 添加共享库
我们现在需要完成的任务是将目标文件链接到 libhello,这里我们需要引入两个新的指令
LINK_DIRECTORIES 和 TARGET_LINK_LIBRARIES
LINK_DIRECTORIES 的全部语法是:
LINK_DIRECTORIES(directory1 directory2 ...)
这个指令非常简单,添加非标准的共享库搜索路径,比如,在工程内部同时存在共享库和可
执行二进制,在编译时就需要指定一下这些共享库的路径。这个例子中我们没有用到这个指
令。
TARGET_LINK_LIBRARIES 的全部语法是:
TARGET_LINK_LIBRARIES(target library1
library2
...)
这个指令可以用来为 target 添加需要链接的共享库,本例中是一个可执行文件,但是同样
可以用于为自己编写的共享库添加共享库链接。
为了解决我们前面遇到的 HelloFunc 未定义错误,我们需要作的是向
src/CMakeLists.txt 中添加如下指令:
TARGET_LINK_LIBRARIES(main hello)
也可以写成
TARGET_LINK_LIBRARIES(main libhello.so)
这里的 hello 指的是我们上一节构建的共享库 libhello.
进入 build 目录重新进行构建。
cmake ..
make
这是我们就得到了一个连接到 libhello 的可执行程序 main,位于 build/src 目录,运
行 main 的结果是输出:
Hello World
让我们来检查一下 main 的链接情况:
ldd src/main
linux-gate.so.1 => (0xb7ee7000)
libhello.so.1 => /usr/lib/libhello.so.1
(0xb7ece000)
libc.so.6 => /lib/libc.so.6 (0xb7d77000)
/lib/ld-linux.so.2 (0xb7ee8000)
可以清楚的看到 main 确实链接了共享库 libhello,而且链接的是动态库
libhello.so.1
那如何链接到静态库呢?
方法很简单:
将 TARGET_LINK_LIBRRARIES 指令修改为:
TARGET_LINK_LIBRARIES(main libhello.a)
重新构建后再来看一下 main 的链接情况
ldd src/main
linux-gate.so.1 => (0xb7fa8000)
libc.so.6 => /lib/libc.so.6 (0xb7e3a000)
/lib/ld-linux.so.2 (0xb7fa9000)
说明,main 确实链接到了静态库 libhello.a
6,特殊的环境变量 CMAKE_INCLUDE_PATH 和 CMAKE_LIBRARY_PATH
务必注意,这两个是环境变量而不是 cmake 变量。
使用方法是要在 bash 中用 export 或者在 csh 中使用 set 命令设置或者
CMAKE_INCLUDE_PATH=/home/include cmake ..等方式。
这两个变量主要是用来解决以前 autotools 工程中
--extra-include-dir 等参数的支持的。
也就是,如果头文件没有存放在常规路径(/usr/include, /usr/local/include 等),
则可以通过这些变量就行弥补。
我们以本例中的 hello.h 为例,它存放在/usr/include/hello 目录,所以直接查找肯
定是找不到的。
前面我们直接使用了绝对路径 INCLUDE_DIRECTORIES(/usr/include/hello)告诉工
程这个头文件目录。
为了将程序更智能一点,我们可以使用 CMAKE_INCLUDE_PATH 来进行,使用 bash 的方法
如下:
export CMAKE_INCLUDE_PATH=/usr/include/hello
然后在头文件中将 INCLUDE_DIRECTORIES(/usr/include/hello)替换为:
FIND_PATH(myHeader hello.h)
IF(myHeader)
INCLUDE_DIRECTORIES(${myHeader})
ENDIF(myHeader)
上述的一些指令我们在后面会介绍。
这里简单说明一下,FIND_PATH 用来在指定路径中搜索文件名,比如:
FIND_PATH(myHeader NAMES hello.h PATHS /usr/include
/usr/include/hello)
这里我们没有指定路径,但是,cmake 仍然可以帮我们找到 hello.h 存放的路径,就是因
为我们设置了环境变量 CMAKE_INCLUDE_PATH。
如果你不使用 FIND_PATH,CMAKE_INCLUDE_PATH 变量的设置是没有作用的,你不能指
望它会直接为编译器命令添加参数-I。
以此为例,CMAKE_LIBRARY_PATH 可以用在 FIND_LIBRARY 中。
同样,因为这些变量直接为 FIND_指令所使用,所以所有使用 FIND_指令的 cmake 模块都
会受益。
7,小节:
本节我们探讨了:
如何通过 INCLUDE_DIRECTORIES 指令加入非标准的头文件搜索路径。
如何通过 LINK_DIRECTORIES 指令加入非标准的库文件搜索路径。
如果通过 TARGET_LINK_LIBRARIES 为库或可执行二进制加入库链接。
并解释了如果链接到静态库。
到这里为止,您应该基本可以使用 cmake 工作了,但是还有很多高级的话题没有探讨,比
如编译条件检查、编译器定义、平台判断、如何跟 pkgconfig 配合使用等等。
到这里,或许你可以理解前面讲到的“cmake 的使用过程其实就是学习 cmake 语言并编写
cmake 程序的过程”,既然是“cmake 语言”,自然涉及到变量、语法等.
下一节,我们将抛开程序的话题,看看常用的 CMAKE 变量以及一些基本的控制语法规则。
七,cmake 常用变量和常用环境变量
一,cmake 变量引用的方式:
前面我们已经提到了,使用${}进行变量的引用。在 IF 等语句中,是直接使用变量名而不
通过${}取值
二,cmake 自定义变量的方式:
主要有隐式定义和显式定义两种,前面举了一个隐式定义的例子,就是 PROJECT 指令,他
会隐式的定义_BINARY_DIR
和_SOURCE_DIR 两个变
量。
显式定义的例子我们前面也提到了,使用 SET 指令,就可以构建一个自定义变量了。
比如:
SET(HELLO_SRC main.SOURCE_PATHc),就 PROJECT_BINARY_DIR 可以通过
${HELLO_SRC}来引用这个自定义变量了.
三,cmake 常用变量:
1,CMAKE_BINARY_DIR
PROJECT_BINARY_DIR
_BINARY_DIR
这三个变量指代的内容是一致的,如果是 in source 编译,指得就是工程顶层目录,如果
是 out-of-source 编译,指的是工程编译发生的目录。PROJECT_BINARY_DIR 跟其他
指令稍有区别,现在,你可以理解为他们是一致的。
2,CMAKE_SOURCE_DIR
PROJECT_SOURCE_DIR
_SOURCE_DIR
这三个变量指代的内容是一致的,不论采用何种编译方式,都是工程顶层目录。
也就是在 in source 编译时,他跟 CMAKE_BINARY_DIR 等变量一致。
PROJECT_SOURCE_DIR 跟其他指令稍有区别,现在,你可以理解为他们是一致的。
3,CMAKE_CURRENT_SOURCE_DIR
指的是当前处理的 CMakeLists.txt 所在的路径,比如上面我们提到的 src 子目录。
4,CMAKE_CURRRENT_BINARY_DIR
如果是 in-source 编译,它跟 CMAKE_CURRENT_SOURCE_DIR 一致,如果是 out-of-
source 编译,他指的是 target 编译目录。
使用我们上面提到的 ADD_SUBDIRECTORY(src bin)可以更改这个变量的值。
使用 SET(EXECUTABLE_OUTPUT_PATH
<新路径>)并不会对这个变量造成影响,它仅仅
修改了最终目标文件存放的路径。
5,CMAKE_CURRENT_LIST_FILE
输出调用这个变量的 CMakeLists.txt 的完整路径
6,CMAKE_CURRENT_LIST_LINE
输出这个变量所在的行
7,CMAKE_MODULE_PATH
这个变量用来定义自己的 cmake 模块所在的路径。如果你的工程比较复杂,有可能会自己
编写一些 cmake 模块,这些 cmake 模块是随你的工程发布的,为了让 cmake 在处理
CMakeLists.txt 时找到这些模块,你需要通过 SET 指令,将自己的 cmake 模块路径设
置一下。
比如
SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
这时候你就可以通过 INCLUDE 指令来调用自己的模块了。
8,EXECUTABLE_OUTPUT_PATH 和 LIBRARY_OUTPUT_PATH
分别用来重新定义最终结果的存放目录,前面我们已经提到了这两个变量。
9,PROJECT_NAME
返回通过 PROJECT 指令定义的项目名称。
四,cmake 调用环境变量的方式
使用$ENV{NAME}指令就可以调用系统的环境变量了。
比如
MESSAGE(STATUS “HOME dir: $ENV{HOME}”)
设置环境变量的方式是:
SET(ENV{变量名} 值)
1,CMAKE_INCLUDE_CURRENT_DIR
自动添加 CMAKE_CURRENT_BINARY_DIR 和 CMAKE_CURRENT_SOURCE_DIR
到当前处理
的 CMakeLists.txt。相当于在每个 CMakeLists.txt 加入:
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR})
2,CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
将工程提供的头文件目录始终至于系统头文件目录的前面,当你定义的头文件确实跟系统发
生冲突时可以提供一些帮助。
3,CMAKE_INCLUDE_PATH 和 CMAKE_LIBRARY_PATH 我们在上一节已经提及。