Translation: Building Qt Projects with CMake
Author: Johan Thelin Translator: Lai Jingwen
Original link: http://developer.qt.nokia.com/quarterly/view/using_cmake_to_build_qt_projectsTranslation
source: http://blog.csdn.net/jingwenlai_scut
QMake is already included in the QtSDK to handle cross-platform compilation issues. However, other compilation tools exist, such as autotools, SCons and CMake. These tools meet different needs, such as external dependencies.
When a KDE project was upgraded from using Qt3 to using Qt4, the entire project switched its build tools from autotools to CMake. This gave CMake a special place in the Qt development world in terms of number of users and feature support and quality. From the perspective of development process, QtCreator supports CMake since 1.1 (supports Microsoft's development toolset since 1.3).
1. A basic example
In this article we will only focus on CMake itself, and point out how to combine it with Qt. First, let's look at a simple but typical CMake-based project. As you can see from the list below, this project includes some source code and text files.
$ ls
CMakeLists.txt
hellowindow.cpp
hellowindow.h
main.cpp
The most basic, CMakeLists.txt file replaces the project files that QMake needs to use. If you need to compile this project, you can create a build directory and use cmake and make to compile it.
$ mkdir build
$ cd build
$ cmake .. && make
The reason for creating a build directory is that we want to achieve the purpose of "out-of-source" compilation, that is, we can isolate the intermediate files generated during the compilation process from the source code . Of course, this can be done with qmake as well, but with a few extra steps, but CMake can do it easily.
CMake is compiling a basic project
The parameter representation used in CMake refers to the directory where the CMakeLists.txt file is located. This CMakeLists.txt file controls the entire compilation process. To understand it more thoroughly, let's take a look at the entire compilation process with the following diagram. The following figure shows how user-written files (source code, header files, .ui files, .qrc files) are processed by Qt tools during the compilation process and integrated into the entire compilation process. Because qmake is used to handle this process, it hides many details in this process.
When using the Qt build system
with CMake, these intermediate processes must be handled explicitly. That is to say, if the Q_OBJECT macro is used in the header file, the file needs to be processed by moc, the .ui file must also be processed by uic, and the .qrc file needs to be processed by the rcc program.
In the above example, we have simplified these steps, we only need to deal with the header file that contains the Q_OBJECT macro. That is to say, we need to use moc to process the helloworld.h file. The CMakeLists.txt file corresponding to this project is as follows:
PROJECT(helloworld)
FIND_PACKAGE(Qt4 REQUIRED)
The meaning of the above two sentences means to define this project as helloworld, and let cmake automatically find Qt4. Next, we need to use the SET command to The defined header file is linked with the cpp file, etc.
SET(helloworld_SOURCES main.cpp hellowindow.cpp)
SET(helloworld_HEADERS hellowindow.h)
In order to call the moc program, you need to use the QT4_WRAP_CPP macro. The definition is as follows:
QT4_WRAP_CPP(helloworld_HEADERS_MOC ${helloworld_HEADERS})
This step is actually the same as using
$moc on the command line –o helloworld_moc.h helloworld.h
It is similar, the above helloworld_HEADERS_MOC is just a name for subsequent use.
In order to compile this Qt project, you need to include the Qt library file directory and include some definitions:
INCLUDE(${QT_USE_FILE})
ADD_DEFINITIONS(${QT_DEFINITIONS})
Finally, CMake needs to know the name of the final application and add the link library to generate it. This can easily use ADD_EXECUTABLE and TARGET_LINK_LIBRARIES in cmake. Therefore, add the following to CMakeLists.txt:
ADD_EXECUTABLE(helloworld ${helloworld_SOURCES}
${helloworld_HEADERS_MOC})
TARGET_LINK_LIBRARIES(helloworld ${QT_LIBRARIES})
Revisit the above CMakeLists.txt, You will feel that compared to qmake, you need to write more configuration, which is actually greatly simplified, because cmake is not used exclusively for Qt like qmake.
2. Add more Qt elements
Continuing from the most basic example above, we are adding resource files and UI files. In the above example, the hellowindow.ui and images.qrc files are added, and the corresponding CMakeLists.txt is added with the following content:
SET(helloworld_SOURCES main.cpp hellowindow.cpp)
SET(helloworld_HEADERS hellowindow.h)
SET(helloworld_FORMS hellowindow.ui)
SET(helloworld_RESOURCES images.qrc)
.qrc files and .ui files are processed by macros QT4_WRAP_UI and QT4_ADD_RESOURCES. The functions of these macros are the same as those of QT4_WRAP_CPP. In fact, they are processed by calling the corresponding application program during the compilation process. That is, the .qrc file is processed by calling the rcc program, and the .ui file is processed by calling the uic program. Add the following content to CMakeLists.txt:
QT4_WRAP_CPP(helloworld_HEADERS_MOC ${helloworld_HEADERS})
QT4_WRAP_UI(helloworld_FORMS_HEADERS ${helloworld_FORMS})
QT4_ADD_RESOURCES(helloworld_RESOURCES_RCC ${helloworld_RESOURCES})
Similarly, these intermediate generated files need to be used when the application is finally generated. Therefore, add_executable is modified as follows:
ADD_EXECUTABLE(helloworld ${helloworld_SOURCES}
${ helloworld_HEADERS_MOC}
${helloworld_FORMS_HEADERS}
${helloworld_RESOURCES_RCC})
Before compiling, there is one more problem to be dealt with. As mentioned above, we are compiling outside the source code, so these generated intermediate files will be in the build directory In this case, the compiler cannot locate files such as ui_hellowindow.h generated by the uic program. So, we need to add the build directory to the include directory as follows:
After INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}) is
added to this line, all intermediate generated files will be included in the include path.
3. More Qt modules
So far, we only rely on QtCore and QtGui modules. If you need to reference other modules, cmake needs to explicitly enable it. A specific module can be set to TRUE through the set command. For example, if you want to use OpenGL support in your program, you need to use the following line in CMakeLists.txt:
SET(QT_USE_QTOPENGL TRUE)
Other more commonly used modules include:
QT_USE_QTNETWORK
QT_USE_QTOPENGL
QT_USE_QTSQL
QT_USE_QTXML
QT_USE_QTSVG
QT_USE_QTTEST
QT_USE_QTDBUS
QT_USE_QTSCRIPT
QT_USE_QTWEBKIT
QT_USE_QTXMLPATTERNS
QT_USE_PHONON
In addition, there are other macros that can be used, for details, please refer to cmake/share/Modules/FindQt4.cmake
4. Balance between benefits and complexity
As you can see above, using cmake is not as easy as qmake, but cmake Provides more functions. The most notable benefit is that cmake supports "out-of-source" compilation, which may change usage habits, but makes version tracking of source code much more convenient.
Also, another benefit of using cmake is that not just for Qt, cmake makes it easier to add support for additional libraries, for example, for different platforms, linking different libraries or using Qt with other libraries to build For larger programs, the advantages of cmake begin to emerge at this time.
Another powerful feature is the ability to generate different versions of the application in one setup process, that is, for a single configuration file, multiple different compilation processes can be generated.
The choice between Cmake and qmake is actually very simple. For projects that only use Qt, qmake is a good first choice. When the compilation requirements exceed the processing capacity of qmake or the configuration using qmake becomes very complicated, cmake can replace it