Qt自带集成开发环境（IDE），名为Qt Creator。它可以在Linux、OS X和Windows上运行，并提供智能代码完成、语法高亮、集成帮助系统、调试器和剖析器集成，还集成了所有主要的版本控制系统（如git、Bazaar）。除了Qt Creator外，Windows上的开发人员还可以使用Qt的Visual Studio插件。也可以使用其他的IDE（如KDE上的KDevelop）。但当然绝不是必须使用任何IDE。
一年半前，Qt做出了一个重大决定，开始使用CMake来构建Qt 6。做出此决定的主要原因是用户反馈。大多数Qt用户希望更轻松地将他们的Qt项目与其他软件集成在一起。根据当时的研究，CMake显然是Qt用户中最常用的构建工具-除了qmake。此外，迁移到CMake还为我们提供了摆脱内部构建工具维护负担的机会。
比决定更大的是迁移到CMake所需的工作。现在，基本的迁移工作已经完成，现在该分享我们的发现了。
尽管已被许多项目很好地建立和使用，但CMake缺少了先前Qt构建工具所支持的一些关键功能。这就是为什么我们与Kitware合作消除障碍并改善CMake的原因，从而使Qt项目和更大的CMake社区受益。
由于各种因素，构建Qt很复杂：
- Qt支持许多平台。
- Qt分为可独立构建或全部构建的模块。
- Qt支持不同的构建方式（前缀，非前缀，不同的功能集）
让我们看一下Qt的构建工具开关引起或影响的CMake改进。
Qt相关组件：
- QtitanRibbon| 下载试用: 遵循Microsoft Ribbon UI Paradigm for Qt技术的Ribbon UI组件，致力于为Windows、Linux和Mac OS X提供功能完整的Ribbon组件。
- QtitanChart | 下载试用 :是一个C ++库，代表一组控件，这些控件使您可以快速地为应用程序提供漂亮而丰富的图表。并且支持所有主要的桌面操作系统。
- QtitanDataGrid | 下载试用 :这个Qt数据网格组件使用纯C++创建，运行速度极快，处理大数据和超大数据集的效果突出。QtitanDataGrid完全集成了QtDesigner，因而极易适应其他相似的开发环境，保证100%兼容Qt GUI。
预编译头
在C ++项目中，可能会一遍又一遍地包含相同的头文件。对于库头尤其如此。如果工具链支持，则可以通过预编译头文件来加快编译速度。
在最长的时间内，CMake并未为此提供现成的支持。但是，在网上搜索代码片段以启用CMake中的预编译头的日子已经过去。从CMake 3.16开始，使用该target_precompile_headers命令可以添加要预编译的头文件列表。
Unity构建
另一种加快编译速度的方法是unity builds。这就是多名技术--它也被称为巨型构建、合并构建和单一编译单元。
这种技术创建了一个包含所有其他源文件的源文件，并且只编译这一个源文件。
#include "source_file1.cpp"
#include "source_file2.cpp"
/*...*/
#include "source_file8.cpp"
所有源文件的包含文件仅被处理一次，所有内容都以一个翻译单元结束，并且优化器对项目具有全局视图。
但是，并非每个C ++项目都可以不加修改地利用统一构建。
depfile支持AUTOMOC + Ninja
长期以来，人们一直在抱怨CMake的AUTOMOC，它会不必要地运行，或者在再次调用moc时无法正确检测到。原因之一是moc输出的确切依赖关系对于AUTOMOC是不可见的。
从Qt 5.15开始，moc学会了写出准确的文件，这些文件构成了moc输出的依赖性。CMake 3.17学会了读取moc的depfiles并将其用于Ninja生成器。
总结一下：使用Ninja生成器的Qt> = 5.15和CMake> = 3.17时，AUTOMOC知道正确的依赖项，可以在正确的时间重新运行moc。
Ninja Multi-Config
在Windows和macOS上，传统上Qt是用两种配置（调试和发布）构建的，但在一个构建目录中。
直到版本3.17引入了一个名为“ Ninja Multi-Config”的新生成器后，CMake才提供实现此目的的方法，该生成器可以一次构建多个配置。
iOS多架构构建
适用于iOS的Qt提供了模拟器和设备版本，该版本将针对实际目标构建的Qt与针对iOS模拟器构建的Qt相结合。尽管CMake 3.17引入了Ninja Multi-Config，但它的iOS支持尚未为iOS多体系结构构建做好准备。
CMake 3.18解决了这个问题，我们可以很高兴地为模拟器和设备进行构建。
文件（配置）
在Qt构建中，在配置时会生成大量带有动态创建内容的文件。configure_file但是，该命令仅使用输入文件，不使用字符串。
解决此问题的一种方法是让输入文件只有一个变量
--conf-file-content.txt.in--
@my-conf-file-content@
然后像这样调用configure_file
set(my-conf-file-content "This is the generated content!")
configure_file("my-conf-file-content.txt.in" "output.txt" @ONLY)
在CMake 3.18中，我们可以轻松实现相同目标：
file(CONFIGURE OUTPUT "output.txt" CONTENT "This is the generated content!")
评估！与功能同盟！
在Qt构建中，我们用尽了CMake语言作为实际编程语言执行的能力。不仅应该由用户调用CMake函数，而且在引擎盖下还有更复杂的设备。
让我们烦恼的一件事是，不可能动态调用函数。在qmake中，可以调用在变量中定义的函数，并且Qt5版本广泛使用此功能。
f = message
$${f}("Hello World!")
有多种方法可以使此工作在CMake中进行，包括生成一个随后包含的文件，但是特别是在Windows上，这将极大地减慢项目配置步骤。
CMake 3.18随附cmake_language(EVAL)用于评估CMake代码并cmake_language(CALL)调用宏或函数。
set(f "message")
cmake_language(CALL ${f} STATUS "Hello World!")
cmake_language(EVAL CODE "${f}(\"Hello World!\")")
稍后致电-延迟的代码
同样，qmake功能启发了CMake命令。
在QMake项目中，可以编写CONFIG += foo，然后在mkspecs/features/foo.prf处理实际的项目文件后加载。
这对于面向用户的API尤其有用。假设您正在为Android创建一个项目。
qt_add_executable(MyApp)
set_property(MyApp TARGET PROPERTY QT_ANDROID_EXTRA_LIBS SuperDuperLib)
qt_finalize_executable(MyApp)
该qt_finalize_executable调用将根据目标的属性为目标生成适当的部署设置。如果用户忘记致电qt_finalize_executable，则不会生成部署设置，也不会出现错误或警告。
但是，如果用户摆脱了打电话的负担，那会不会很棒qt_finalize_executable？在CMake 3.19中，Qt构建利用了新命令cmake_language(DEFER CALL)。这样一来，就可以在定义的时间调用函数，例如，在评估当前目录的项目文件之后。
不同目录范围的源文件上的属性
在某些地方，我们为模块创建目标，然后在子目录中将源文件添加到该目标。这样可以使源文件的名称与CMakeLists.txt文件保持接近。
但是，无法在这些位置指定每个源文件的属性-我们必须进入层次结构的顶层才能进行设置。我们并不经常这样做，但是有时在开发过程中会出现这种情况，以允许根据选项设置在编译时选择实验功能。
在CMake 3.18中，set_source_files_properties学会了在不同目录范围内设置属性：
该DIRECTORY选项获取指向处理后的源目录的路径的列表，并TARGET_DIRECTORY获取目标的列表，这些目标的源目录将用作设置源文件属性的作用域列表。
get_property()并且get_source_file_property()还具有相同的新参数，除了只能指定一个值而不是列表。
add_custom_command DEPFILE支持Makefile
CMake 3.20将为Unix Makefile生成器提供depfile支持。这也是将moc生成的depfile用于Makefile的前提。