- 最大的Qt4程序群(KDE4)采用cmake作为构建系统
- Qt4的python绑定(pyside)采用了cmake作为构建系统
- 开源的图像处理库 opencv 采用cmake 作为构建系统
- ...
看来不学习一下cmake是不行了，一点一点来吧，找个最简单的C程序，慢慢复杂化，试试看：
例子一 | 单个源文件 main.c |
例子二 | ==>分解成多个 main.c hello.h hello.c |
例子三 | ==>先生成一个静态库，链接该库 |
例子四 | ==>将源文件放置到不同的目录 |
例子五 | ==>控制生成的程序和库所在的目录 |
例子六 | ==>使用动态库而不是静态库 |
例子一
一个经典的C程序，如何用cmake来进行构建程序呢？
//main.c
#include
int main()
{
printf("Hello World!/n");
return 0;
}
编写一个 CMakeList.txt 文件(可看做cmake的工程文件)：
project(HELLO)
set(SRC_LIST main.c)
add_executable(hello ${SRC_LIST})
然后，建立一个任意目录（比如本目录下创建一个build子目录），在该build目录下调用cmake
- 注意：为了简单起见，我们从一开始就采用cmake的 out-of-source 方式来构建（即生成中间产物与源代码分离），并始终坚持这种方法，这也就是此处为什么单独创建一个目录，然后在该目录下执行 cmake 的原因
cmake .. -G"NMake Makefiles" nmake
或者
cmake .. -G"MinGW Makefiles" make
即可生成可执行程序 hello(.exe)
目录结构
+ | +--- main.c +--- CMakeList.txt | /--+ build/ | +--- hello.exe
cmake 真的不太好用哈，使用cmake的过程，本身也就是一个编程的过程，只有多练才行。
我们先看看：前面提到的这些都是什么呢？
CMakeList.txt
第一行 project 不是强制性的，但最好始终都加上。这一行会引入两个变量
- HELLO_BINARY_DIR 和 HELLO_SOURCE_DIR
同时，cmake自动定义了两个等价的变量
PROJECT_BINARY_DIR 和 PROJECT_SOURCE_DIR
因为是out-of-source方式构建，所以我们要时刻区分这两个变量对应的目录
可以通过message来输出变量的值
message(${PROJECT_SOURCE_DIR})
set 命令用来设置变量
add_exectuable 告诉工程生成一个可执行文件。
add_library 则告诉生成一个库文件。
- 注意：CMakeList.txt 文件中，命令名字是不区分大小写的，而参数和变量是大小写相关的。
cmake命令
cmake 命令后跟一个路径(..)，用来指出 CMakeList.txt 所在的位置。
由于系统中可能有多套构建环境，我们可以通过-G来制定生成哪种工程文件，通过 cmake -h 可得到详细信息。
要显示执行构建过程中详细的信息(比如为了得到更详细的出错信息)，可以在CMakeList.txt内加入：
- SET( CMAKE_VERBOSE_MAKEFILE on )
或者执行make时
- $ make VERBOSE=1
或者
- $ export VERBOSE=1
- $ make
例子二
一个源文件的例子一似乎没什么意思，拆成3个文件再试试看：
- hello.h 头文件
#ifndef DBZHANG_HELLO_ #define DBZHANG_HELLO_ void hello(const char* name); #endif //DBZHANG_HELLO_
- hello.c
#include
#include "hello.h"
void hello(const char * name)
{
printf ("Hello %s!/n", name);
}
- main.c
#include "hello.h"
int main()
{
hello("World");
return 0;
}
- 然后准备好CMakeList.txt 文件
project(HELLO)
set(SRC_LIST main.c hello.c)
add_executable(hello ${SRC_LIST})
执行cmake的过程同上，目录结构
+ | +--- main.c +--- hello.h +--- hello.c +--- CMakeList.txt | /--+ build/ | +--- hello.exe
例子很简单，没什么可说的。
例子三
接前面的例子，我们将 hello.c 生成一个库，然后再使用会怎么样？
改写一下前面的CMakeList.txt文件试试：
project(HELLO)
set(LIB_SRC hello.c)
set(APP_SRC main.c)
add_library(libhello ${LIB_SRC})
add_executable(hello ${APP_SRC})
target_link_libraries(hello libhello)
和前面相比，我们添加了一个新的目标 libhello，并将其链接进hello程序
然后想前面一样，运行cmake，得到
+ | +--- main.c +--- hello.h +--- hello.c +--- CMakeList.txt | /--+ build/ | +--- hello.exe +--- libhello.lib
里面有一点不爽，对不？
- 因为我的可执行程序(add_executable)占据了 hello 这个名字，所以 add_library 就不能使用这个名字了
- 然后，我们去了个libhello 的名字，这将导致生成的库为 libhello.lib(或 liblibhello.a)，很不爽
- 想生成 hello.lib(或libhello.a) 怎么办?
添加一行
set_target_properties(libhello PROPERTIES OUTPUT_NAME "hello")
就可以了
例子四
在前面，我们成功地使用了库，可是源代码放在同一个路径下，还是不太正规，怎么办呢？分开放呗
我们期待是这样一种结构
+ | +--- CMakeList.txt +--+ src/ | | | +--- main.c | /--- CMakeList.txt | +--+ libhello/ | | | +--- hello.h | +--- hello.c | /--- CMakeList.txt | /--+ build/
哇，现在需要3个CMakeList.txt 文件了，每个源文件目录都需要一个，还好，每一个都不是太复杂
- 顶层的CMakeList.txt 文件
project(HELLO) add_subdirectory(src) add_subdirectory(libhello)
- src 中的 CMakeList.txt 文件
include_directories(${PROJECT_SOURCE_DIR}/libhello)
set(APP_SRC main.c)
add_executable(hello ${APP_SRC})
target_link_libraries(hello libhello)
- libhello 中的 CMakeList.txt 文件
set(LIB_SRC hello.c)
add_library(libhello ${LIB_SRC})
set_target_properties(libhello PROPERTIES OUTPUT_NAME "hello")
恩，和前面一样，建立一个build目录，在其内运行cmake，然后可以得到
- build/src/hello.exe
- build/libhello/hello.lib
回头看看，这次多了点什么，顶层的 CMakeList.txt 文件中使用 add_subdirectory 告诉cmake去子目录寻找新的CMakeList.txt 子文件
在 src 的 CMakeList.txt 文件中，新增加了include_directories，用来指明头文件所在的路径。
例子五
前面还是有一点不爽：如果想让可执行文件在 bin 目录，库文件在 lib 目录怎么办？
就像下面显示的一样：
+ build/
|
+--+ bin/
| |
| /--- hello.exe
|
/--+ lib/
|
/--- hello.lib
- 一种办法：修改顶级的 CMakeList.txt 文件
project(HELLO) add_subdirectory(src bin) add_subdirectory(libhello lib)
不是build中的目录默认和源代码中结构一样么，我们可以指定其对应的目录在build中的名字。
这样一来：build/src 就成了 build/bin 了，可是除了 hello.exe，中间产物也进来了。还不是我们最想要的。
- 另一种方法：不修改顶级的文件，修改其他两个文件
src/CMakeList.txt 文件
include_directories(${PROJECT_SOURCE_DIR}/libhello)
#link_directories(${PROJECT_BINARY_DIR}/lib)
set(APP_SRC main.c)
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
add_executable(hello ${APP_SRC})
target_link_libraries(hello libhello)
libhello/CMakeList.txt 文件
set(LIB_SRC hello.c)
add_library(libhello ${LIB_SRC})
set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
set_target_properties(libhello PROPERTIES OUTPUT_NAME "hello")
例子六
在例子三至五中，我们始终用的静态库，那么用动态库应该更酷一点吧。 试着写一下
如果不考虑windows下，这个例子应该是很简单的，只需要在上个例子的 libhello/CMakeList.txt 文件中的add_library命令中加入一个SHARED参数：
add_library(libhello SHARED ${LIB_SRC})
可是，我们既然用cmake了，还是兼顾不同的平台吧，于是，事情有点复杂：
- 修改 hello.h 文件
#ifndef DBZHANG_HELLO_
#define DBZHANG_HELLO_
#if defined _WIN32
#if LIBHELLO_BUILD
#define LIBHELLO_API __declspec(dllexport)
#else
#define LIBHELLO_API __declspec(dllimport)
#endif
#else
#define LIBHELLO_API
#endif
LIBHELLO_API void hello(const char* name);
#endif //DBZHANG_HELLO_
- 修改 libhello/CMakeList.txt 文件
set(LIB_SRC hello.c)
add_definitions("-DLIBHELLO_BUILD")
add_library(libhello SHARED ${LIB_SRC})
set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
set_target_properties(libhello PROPERTIES OUTPUT_NAME "hello")
恩，剩下来的工作就和原来一样了。
在 Cmake学习笔记一 中通过一串小例子简单学习了cmake 的使用方式。
这次应该简单看看语法和常用的命令了。
简单的语法
- 注释
# 我是注释
- 命令语法
COMMAND(参数1 参数2 ...)
- 字符串列表
A;B;C # 分号分割或空格分隔的值
- 变量(字符串或字符串列表)
set(Foo a b c) | 设置变量 Foo |
command(${Foo}) | 等价于 command(a b c) |
command("${Foo}") | 等价于 command("a b c") |
command("/${Foo}") | 转义，和 a b c无关联 |
- 流控制结构
IF()...ELSE()/ELSEIF()...ENDIF() WHILE()...ENDWHILE() FOREACH()...ENDFOREACH()
- 正则表达式
部分常用命令
INCLUDE_DIRECTORIES( "dir1" "dir2" ... ) | 头文件路径，相当于编译器参数 -Idir1 -Idir2 |
LINK_DIRECTORIES("dir1" "dir2") | 库文件路径。注意： |
AUX_SOURCE_DIRECTORY( “sourcedir” variable) | 收集目录中的文件名并赋值给变量 |
ADD_EXECUTABLE | 可执行程序目标 |
ADD_LIBRARY | 库目标 |
ADD_CUSTOM_TARGET | 自定义目标 |
ADD_DEPENDENCIES( target1 t2 t3 ) | 目标target1依赖于t2 t3 |
ADD_DEFINITIONS( "-Wall -ansi") | 本意是供设置 -D... /D... 等编译预处理需要的宏定义参数，对比 REMOVE_DEFINITIONS() |
TARGET_LINK_LIBRARIES( target-name lib1 lib2 ...) | 设置单个目标需要链接的库 |
LINK_LIBRARIES( lib1 lib2 ...) | 设置所有目标需要链接的库 |
SET_TARGET_PROPERTIES( ... ) | 设置目标的属性 OUTPUT_NAME, VERSION, .... |
MESSAGE(...) | |
INSTALL( FILES “f1” “f2”DESTINATION . ) | DESTINATION 相对于 ${CMAKE_INSTALL_PREFIX} |
SET( VAR value [CACHE TYPE DOCSTRING [FORCE]]) | |
LIST( APPEND|INSERT|LENGTH|GET| REMOVE_ITEM|REMOVE_AT|SORT ...) | 列表操作 |
STRING( TOUPPER|TOLOWER|LENGTH| SUBSTRING|REPLACE|REGEX ...) | 字符串操作 |
SEPARATE_ARGUMENTS( VAR ) | 转换空格分隔的字符串到列表 |
FILE( WRITE|READ|APPEND|GLOB| GLOB_RECURSE|REMOVE|MAKE_DIRECTORY ...) | 文件操作 |
FIND_FILE | 注意 CMAKE_INCLUDE_PATH |
FIND_PATH | 注意 CMAKE_INCLUDE_PATH |
FIND_LIBRARY | 注意 CMAKE_LIBRARY_PATH |
FIND_PROGRAM | |
FIND_PACKAGE | 注意 CMAKE_MODULE_PATH |
EXEC_PROGRAM( bin [work_dir] ARGS <..> [OUTPUT_VARIABLE var] [RETURN_VALUE var] ) | 执行外部程序 |
OPTION( OPTION_VAR “description” [initial value] ) |
变量
工程路径
- CMAKE_SOURCE_DIR
- PROJECT_SOURCE_DIR
_SOURCE_DIR
这三个变量指代的内容是一致的，是工程顶层目录
- CMAKE_BINARY_DIR
- PROJECT_BINARY_DIR
_BINARY_DIR
这三个变量指代的内容是一致的，如果是in source编译，指得就是工程顶层目录，如果 是out-of-source编译，指的是工程编译发生的目录
CMAKE_CURRENT_SOURCE_DIR
指的是当前处理的CMakeLists.txt所在的路径。
CMAKE_CURRRENT_BINARY_DIR
如果是in-source编译，它跟CMAKE_CURRENT_SOURCE_DIR一致，如果是out-ofsource 编译，他指的是target编译目录。
CMAKE_CURRENT_LIST_FILE
输出调用这个变量的CMakeLists.txt的完整路径
CMAKE_BUILD_TYPE
控制 Debug 和 Release 模式的构建
- CMakeList.txt文件
SET(CMAKE_BUILD_TYPE Debug)
- 命令行参数
cmake DCMAKE_BUILD_TYPE=Release
编译器参数
- CMAKE_C_FLAGS
- CMAKE_CXX_FLAGS
也可以通过指令ADD_DEFINITIONS()添加
CMAKE_INCLUDE_PATH
- 配合 FIND_FILE() 以及 FIND_PATH() 使用。如果头文件没有存放在常规路径(/usr/include, /usr/local/include等)，
则可以通过这些变量就行弥补。如果不使用 FIND_FILE 和 FIND_PATH的话，CMAKE_INCLUDE_PATH，没有任何作用。
CMAKE_LIBRARY_PATH
配合 FIND_LIBRARY() 使用。否则没有任何作用
CMAKE_MODULE_PATH
cmake 为上百个软件包提供了查找器(finder):FindXXXX.cmake
当使用非cmake自带的finder时，需要指定finder的路径，这就是CMAKE_MODULE_PATH，配合 FIND_PACKAGE()使用
CMAKE_INSTALL_PREFIX
控制make install是文件会安装到什么地方。默认定义是/usr/local 或 %PROGRAMFILES%
BUILD_SHARED_LIBS
如果不进行设置，使用ADD_LIBRARY且没有指定库类型，默认编译生成的库是静态库。
UNIX 与 WIN32
- UNIX，在所有的类UNIX平台为TRUE，包括OS X和cygwin
- WIN32，在所有的win32平台为TRUE，包括cygwin
参考
- Cmake Practice --Cjacker
学习一下cmake的 finder。
finder是神马东西？
当编译一个需要使用第三方库的软件时，我们需要知道：
去哪儿找头文件 .h | 对比GCC的 -I 参数 |
去哪儿找库文件 (.so/.dll/.lib/.dylib/...) | 对比GCC的 -L 参数 |
需要链接的库文件的名字 | 对比GCC的 -l 参数 |
这也是一个 finder 需要返回的最基本的信息。
如何使用?
比如说，我们需要一个第三方库 curl，那么我们的 CMakeLists.txt 需要指定头文件目录，和库文件，类似：
include_directiories(/usr/include) target_link_libraries(myprogram curl)
如果借助于cmake提供的finder会怎么样呢？使用cmake的Modules目录下的FindCURL.cmake，相应的 CMakeList.txt 文件：
find_package(CURL REQUIRED)
include_directories(${CURL_INCLUDE_DIR})
target_link_libraries(curltest ${CURL_LIBRARY})
或者
find_package(CURL)
if(CURL_FOUND)
include_directories(${CURL_INCLUDE_DIR})
target_link_libraries(curltest ${CURL_LIBRARY})
else(CURL_FOUND)
message(FATAL_ERROR "curl not found!")
endif(CURL_FOUND)
如果我们使用的finder，不是cmake自带的怎么办？
- 放置位置：工程根目录下的 cmake/Modules/
- 然后在 CMakeList.txt 中添加
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
find_package如何工作
find_package 将会在module路径下查找 Find.cmake。首先它搜索 ${CMAKE_MODULE_PATH}中的所有路径，然后搜索 /share/cmake-x.y/Modules/
如果这个文件未找到，它将会查找 Config.cmake 或 -config.cmake 文件。这两个文件是库文件安装时自己安装的，将自己的路径硬编码到其中。
前者称为 module 模式，后者称为 config 模式
每个模块一般都会提供一下几个变量
_FOUND
_INCLUDE_DIR 或 _INCLUDES
_LIBRARY 或 _LIBRARIES 或 _LIBS
_DEFINITIONS
编写finder
- 首先使用 find_package 探测本软件包依赖的第三方库(参数 QUIETLY 和 REQUIRED应该被传递)
- 如果 pkg-config 可用，则可以用其去探测include/library路径
- 分别使用 find_path 和 find_library 查找头文件和库文件
- pkg-config 提供的路径仅作为参考
- CMake 有很多硬编码的路径
结果放到 _INCLUDE_DIR 和 _LIBRARY (注意：单数而不是复数)
设置 _INCLUDE_DIRS 为 _INCLUDE_DIR _INCLUDE_DIRS ...
设置 _LIBRARIES 为 _LIBRARY _LIBRARIES ...
- 依赖使用复数，包自身使用单数形式（由find_path和find_library提供）
调用宏 find_package_handle_standard_args() 设置 _FOUND 并打印或失败信息
参考
CMakeCache.txt
可以将其想象成一个配置文件(在Unix环境下，我们可以认为它等价于传递给configure的参数)。
- CMakeLists.txt 中通过 set(... CACHE ...) 设置的变量
- CMakeLists.txt 中的 option() 提供的选项
- CMakeLists.txt 中find_package() 等find命令引入变量
命令行 cmake . -D := 定义变量
cmake 第一次运行时将生成 CMakeCache.txt 文件，我们可以通过ccmake或cmake-gui或make edit_cache对其进行编辑。
对应于命令行 -D 定义变量，-U 用来删除变量（支持globbing_expr），比如 cmake -U
(W) | |
| (U) |
/(share|lib)(cmake|CMake)/ | (U) |
- find_package 参数及规则见manual
Config.cmake
该文件至少需提供头文件路径和库文件信息。比如 ApiExtractorConfig.cmake 在Windows下一个例子：
# - try to find APIEXTRACTOR
# APIEXTRACTOR_INCLUDE_DIR - Directories to include to use APIEXTRACTOR
# APIEXTRACTOR_LIBRARIES - Files to link against to use APIEXTRACTOR
SET(APIEXTRACTOR_INCLUDE_DIR "D:/shiboken/dist/include/apiextractor")
if(MSVC)
SET(APIEXTRACTOR_LIBRARY "D:/shiboken/dist/lib/apiextractor.lib")
elseif(WIN32)
SET(APIEXTRACTOR_LIBRARY "D:/shiboken/dist/bin/apiextractor.dll")
else()
SET(APIEXTRACTOR_LIBRARY "D:/shiboken/dist/lib/apiextractor.dll")
endif()
该文件是通过 configure_file 机制生成的，我们看看 ApiExtractorConfig.cmake.in 文件：
SET(APIEXTRACTOR_INCLUDE_DIR "@CMAKE_INSTALL_PREFIX@/include/apiextractor@apiextractor_SUFFIX@")
if(MSVC)
SET(APIEXTRACTOR_LIBRARY "@LIB_INSTALL_DIR@/@CMAKE_SHARED_LIBRARY_PREFIX@apiextractor@apiextractor_SUFFIX@@LIBRARY_OUTPUT_SUFFIX@.lib")
elseif(WIN32)
SET(APIEXTRACTOR_LIBRARY "@CMAKE_INSTALL_PREFIX@/bin/@CMAKE_SHARED_LIBRARY_PREFIX@apiextractor@apiextractor_SUFFIX@@LIBRARY_OUTPUT_SUFFIX@@CMAKE_SHARED_LIBRARY_SUFFIX@")
else()
SET(APIEXTRACTOR_LIBRARY "@LIB_INSTALL_DIR@/@CMAKE_SHARED_LIBRARY_PREFIX@apiextractor@apiextractor_SUFFIX@@LIBRARY_OUTPUT_SUFFIX@@CMAKE_SHARED_LIBRARY_SUFFIX@")
endif()
对应的命令(变量的定义略过)
configure_file("${CMAKE_CURRENT_SOURCE_DIR}/ApiExtractorConfig.cmake.in" "${CMAKE_CURRENT_BINARY_DIR}/ApiExtractorConfig.cmake" @ONLY)
ConfigVersion.cmake
该文件用来比对版本是否匹配，看看ApiExtractorConfigVersion.cmake.in 的内容：
set(PACKAGE_VERSION @apiextractor_VERSION@)
if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
set(PACKAGE_VERSION_COMPATIBLE FALSE)
else("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
set(PACKAGE_VERSION_COMPATIBLE TRUE)
if( "${PACKAGE_FIND_VERSION}" STREQUAL "${PACKAGE_VERSION}")
set(PACKAGE_VERSION_EXACT TRUE)
endif( "${PACKAGE_FIND_VERSION}" STREQUAL "${PACKAGE_VERSION}")
endif("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
一般提供设置下面的变量
PACKAGE_VERSION | 完整的版本字符串 |
PACKAGE_VERSION_EXACT | 如果完全匹配为真 |
PACKAGE_VERSION_COMPATIBLE | 如果兼容为真 |
PACKAGE_VERSION_UNSUITABLE | 如果不可用为真 |
find_package进而根据这些设置
_VERSION | full provided version string |
_VERSION_MAJOR | major version if provided, else 0 |
_VERSION_MINOR | minor version if provided, else 0 |
_VERSION_PATCH | patch version if provided, else 0 |
_VERSION_TWEAK | tweak version if provided, else 0 |
参考
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file
希望这是现阶段阻碍阅读shiboken和PySide源码的涉及cmake的最后一个障碍 ^ _^
学习 cmake 的单元测试部分 ctest。
简单使用
最简单的使用ctest的方法，就是在 CMakeLists.txt 添加命令：
enable_testing()
- 该命令需要在源码的根目录文件内。
从这一刻起，就可以在工程中添加add_test命令了
add_test(NAME [CONFIGURATIONS [Debug|Release|...]]
[WORKING_DIRECTORY dir]
COMMAND [arg1 [arg2 ...]])
- name 指定一个名字
- Debug|Release 控制那种配置下生效
- dir 设置工作目录
- command
- 如果是可执行程序目标，则会被cmake替换成生成的程序的全路径
后面的参数可以使用 $<...> 这种语法，比如 $ 指代tgt这个目标的全名
ApiExtractor
继续以 ApiExtractor 为例学习ctest的使用
顶层的CMakeLists.txt文件的内容片段：
option(BUILD_TESTS "Build tests." TRUE)
if (BUILD_TESTS)
enable_testing()
add_subdirectory(tests)
endif()
创建选项，让用户控制是否启用单元测试。如果启用，则添加进 tests 子目录，我们看其CMakeLists.txt文件
- 首先是创建一个declare_test的宏
- 使用 qt4_automoc 进行moc处理
- 生成可执行文件
- 调用 add_test 加入测试
macro(declare_test testname)
qt4_automoc("${testname}.cpp")
add_executable(${testname} "${testname}.cpp")
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${apiextractor_SOURCE_DIR})
target_link_libraries(${testname} ${QT_QTTEST_LIBRARY} ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} apiextractor)
add_test(${testname} ${testname})
endmacro(declare_test testname)
- 后续就简单了,需要的配置文件直接使用configure_file 的 COPYONLY
declare_test(testabstractmetaclass)
declare_test(testabstractmetatype)
declare_test(testaddfunction)
declare_test(testarrayargument)
declare_test(testcodeinjection)
configure_file("${CMAKE_CURRENT_SOURCE_DIR}/utf8code.txt"
"${CMAKE_CURRENT_BINARY_DIR}/utf8code.txt" COPYONLY)
declare_test(testcontainer)
Qt单元测试
QTestLib 模块用起来还是很简单的，我们这儿稍微一下cmake和qmake的一点不同。
- 使用qmake时，我们只需要一个源文件，比如测试 QString 类时，写一个 testqstring.cpp 文件
#include
class TestQString: public QObject
{
Q_OBJECT
private slots:
void toUpper();
};
void TestQString::toUpper()
{
QString str = "Hello";
QCOMPARE(str.toUpper(), QString("HELLO"));
}
QTEST_MAIN(TestQString)
#include "testqstring.moc"
然后pro文件内启用 testlib 模块，其他和普通Qt程序一样了。
- 使用 cmake 时，我们将其分成两个文件
//testqstring.h
#include
class TestQString: public QObject
{
Q_OBJECT
private slots:
void toUpper();
};
与
//testqstring.cpp
void TestQString::toUpper()
{
QString str = "Hello";
QCOMPARE(str.toUpper(), QString("HELLO"));
}
QTEST_MAIN(TestQString)
#include "testqstring.moc"
然后处理方式就是我们前面看到的那个宏了。
QTest宏
随便看下QTest的宏
- QTEST_APPLESS_MAIN
- QTEST_NOOP_MAIN
- QTEST_MAIN
#define QTEST_APPLESS_MAIN(TestObject) /
int main(int argc, char *argv[]) /
{ /
TestObject tc; /
return QTest::qExec(&tc, argc, argv); /
}
#define QTEST_NOOP_MAIN /
int main(int argc, char *argv[]) /
{ /
QObject tc; /
return QTest::qExec(&tc, argc, argv); /
}
#define QTEST_MAIN(TestObject) /
int main(int argc, char *argv[]) /
{ /
QCoreApplication app(argc, argv); /
TestObject tc; /
return QTest::qExec(&tc, argc, argv); /
}
最终都是调用QTest::qExec,Manual中对其有不少介绍了(略)。
扫一扫
838
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
