Qt自帶集成開發環境（IDE），名爲Qt Creator。它能夠在Linux、OS X和Windows上運行，並提供智能代碼完成、語法高亮、集成幫助系統、調試器和剖析器集成，還集成了全部主要的版本控制系統（如git、Bazaar）。除了Qt Creator外，Windows上的開發人員還可使用Qt的Visual Studio插件。也可使用其餘的IDE（如KDE上的KDevelop）。但固然毫不是必須使用任何IDE。git
一年半前，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。
預編譯頭ui
在C ++項目中，可能會一遍又一遍地包含相同的頭文件。對於庫頭尤爲如此。若是工具鏈支持，則能夠經過預編譯頭文件來加快編譯速度。url
在最長的時間內，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的前提。