Qt自帶集成開(kāi)發(fā)環(huán)境（IDE），名為Qt Creator。它可以在Linux、OS X和Windows上運(yùn)行，并提供智能代碼完成、語(yǔ)法高亮、集成幫助系統(tǒng)、調(diào)試器和剖析器集成，還集成了所有主要的版本控制系統(tǒng)（如git、Bazaar）。除了Qt Creator外，Windows上的開(kāi)發(fā)人員還可以使用Qt的Visual Studio插件。也可以使用其他的IDE（如KDE上的KDevelop）。但當(dāng)然絕不是必須使用任何IDE。

點(diǎn)擊下載Qt6最新試用版

一年半前，Qt做出了一個(gè)重大決定，開(kāi)始使用CMake來(lái)構(gòu)建Qt 6。做出此決定的主要原因是用戶反饋。大多數(shù)Qt用戶希望更輕松地將他們的Qt項(xiàng)目與其他軟件集成在一起。根據(jù)當(dāng)時(shí)的研究，CMake顯然是Qt用戶中最常用的構(gòu)建工具-除了qmake。此外，遷移到CMake還為我們提供了擺脫內(nèi)部構(gòu)建工具維護(hù)負(fù)擔(dān)的機(jī)會(huì)。

比決定更大的是遷移到CMake所需的工作。現(xiàn)在，基本的遷移工作已經(jīng)完成，現(xiàn)在該分享我們的發(fā)現(xiàn)了。

盡管已被許多項(xiàng)目很好地建立和使用，但CMake缺少了先前Qt構(gòu)建工具所支持的一些關(guān)鍵功能。這就是為什么我們與Kitware合作消除障礙并改善CMake的原因，從而使Qt項(xiàng)目和更大的CMake社區(qū)受益。

由于各種因素，構(gòu)建Qt很復(fù)雜：

• Qt支持許多平臺(tái)。
• Qt分為可獨(dú)立構(gòu)建或全部構(gòu)建的模塊。
• Qt支持不同的構(gòu)建方式（前綴，非前綴，不同的功能集）

讓我們看一下Qt的構(gòu)建工具開(kāi)關(guān)引起或影響的CMake改進(jìn)。

Qt相關(guān)組件：

• QtitanRibbon| 下載試用: 遵循Microsoft Ribbon UI Paradigm for Qt技術(shù)的Ribbon UI組件，致力于為Windows、Linux和Mac OS X提供功能完整的Ribbon組件。
• QtitanChart | 下載試用 :是一個(gè)C ++庫(kù)，代表一組控件，這些控件使您可以快速地為應(yīng)用程序提供漂亮而豐富的圖表。并且支持所有主要的桌面操作系統(tǒng)。
• QtitanDataGrid | 下載試用 :這個(gè)Qt數(shù)據(jù)網(wǎng)格組件使用純C++創(chuàng)建，運(yùn)行速度極快，處理大數(shù)據(jù)和超大數(shù)據(jù)集的效果突出。QtitanDataGrid完全集成了QtDesigner，因而極易適應(yīng)其他相似的開(kāi)發(fā)環(huán)境，保證100%兼容Qt GUI。

預(yù)編譯頭

在C ++項(xiàng)目中，可能會(huì)一遍又一遍地包含相同的頭文件。對(duì)于庫(kù)頭尤其如此。如果工具鏈支持，則可以通過(guò)預(yù)編譯頭文件來(lái)加快編譯速度。

在最長(zhǎng)的時(shí)間內(nèi)，CMake并未為此提供現(xiàn)成的支持。但是，在網(wǎng)上搜索代碼片段以啟用CMake中的預(yù)編譯頭的日子已經(jīng)過(guò)去。從CMake 3.16開(kāi)始，使用該target_precompile_headers命令可以添加要預(yù)編譯的頭文件列表。

Unity構(gòu)建

另一種加快編譯速度的方法是unity builds。這就是多名技術(shù)--它也被稱為巨型構(gòu)建、合并構(gòu)建和單一編譯單元。

這種技術(shù)創(chuàng)建了一個(gè)包含所有其他源文件的源文件，并且只編譯這一個(gè)源文件。

#include "source_file1.cpp"
#include "source_file2.cpp"
/*...*/
#include "source_file8.cpp"

所有源文件的包含文件僅被處理一次，所有內(nèi)容都以一個(gè)翻譯單元結(jié)束，并且優(yōu)化器對(duì)項(xiàng)目具有全局視圖。

但是，并非每個(gè)C ++項(xiàng)目都可以不加修改地利用統(tǒng)一構(gòu)建。

depfile支持AUTOMOC + Ninja

長(zhǎng)期以來(lái)，人們一直在抱怨CMake的AUTOMOC，它會(huì)不必要地運(yùn)行，或者在再次調(diào)用moc時(shí)無(wú)法正確檢測(cè)到。原因之一是moc輸出的確切依賴關(guān)系對(duì)于AUTOMOC是不可見(jiàn)的。

從Qt 5.15開(kāi)始，moc學(xué)會(huì)了寫(xiě)出準(zhǔn)確的文件，這些文件構(gòu)成了moc輸出的依賴性。CMake 3.17學(xué)會(huì)了讀取moc的depfiles并將其用于Ninja生成器。

總結(jié)一下：使用Ninja生成器的Qt> = 5.15和CMake> = 3.17時(shí)，AUTOMOC知道正確的依賴項(xiàng)，可以在正確的時(shí)間重新運(yùn)行moc。

Ninja Multi-Config

在Windows和macOS上，傳統(tǒng)上Qt是用兩種配置（調(diào)試和發(fā)布）構(gòu)建的，但在一個(gè)構(gòu)建目錄中。

直到版本3.17引入了一個(gè)名為“ Ninja Multi-Config”的新生成器后，CMake才提供實(shí)現(xiàn)此目的的方法，該生成器可以一次構(gòu)建多個(gè)配置。

iOS多架構(gòu)構(gòu)建

適用于iOS的Qt提供了模擬器和設(shè)備版本，該版本將針對(duì)實(shí)際目標(biāo)構(gòu)建的Qt與針對(duì)iOS模擬器構(gòu)建的Qt相結(jié)合。盡管CMake 3.17引入了Ninja Multi-Config，但它的iOS支持尚未為iOS多體系結(jié)構(gòu)構(gòu)建做好準(zhǔn)備。

CMake 3.18解決了這個(gè)問(wèn)題，我們可以很高興地為模擬器和設(shè)備進(jìn)行構(gòu)建。

文件（配置）

在Qt構(gòu)建中，在配置時(shí)會(huì)生成大量帶有動(dòng)態(tài)創(chuàng)建內(nèi)容的文件。configure_file但是，該命令僅使用輸入文件，不使用字符串。

解決此問(wèn)題的一種方法是讓輸入文件只有一個(gè)變量

--conf-file-content.txt.in--
@my-conf-file-content@

然后像這樣調(diào)用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中，我們可以輕松實(shí)現(xiàn)相同目標(biāo)：

file(CONFIGURE OUTPUT "output.txt" CONTENT "This is the generated content!")

評(píng)估！與功能同盟！

在Qt構(gòu)建中，我們用盡了CMake語(yǔ)言作為實(shí)際編程語(yǔ)言執(zhí)行的能力。不僅應(yīng)該由用戶調(diào)用CMake函數(shù)，而且在引擎蓋下還有更復(fù)雜的設(shè)備。

讓我們煩惱的一件事是，不可能動(dòng)態(tài)調(diào)用函數(shù)。在qmake中，可以調(diào)用在變量中定義的函數(shù)，并且Qt5版本廣泛使用此功能。

f = message
$${f}("Hello World!")

有多種方法可以使此工作在CMake中進(jìn)行，包括生成一個(gè)隨后包含的文件，但是特別是在Windows上，這將極大地減慢項(xiàng)目配置步驟。

CMake 3.18隨附cmake_language(EVAL)用于評(píng)估CMake代碼并cmake_language(CALL)調(diào)用宏或函數(shù)。

set(f "message")
cmake_language(CALL ${f} STATUS "Hello World!")
cmake_language(EVAL CODE "${f}(\"Hello World!\")")

稍后致電-延遲的代碼

同樣，qmake功能啟發(fā)了CMake命令。

在QMake項(xiàng)目中，可以編寫(xiě)CONFIG += foo，然后在mkspecs/features/foo.prf處理實(shí)際的項(xiàng)目文件后加載。

這對(duì)于面向用戶的API尤其有用。假設(shè)您正在為Android創(chuàng)建一個(gè)項(xiàng)目。

qt_add_executable(MyApp)
set_property(MyApp TARGET PROPERTY QT_ANDROID_EXTRA_LIBS SuperDuperLib)
qt_finalize_executable(MyApp)

 該qt_finalize_executable調(diào)用將根據(jù)目標(biāo)的屬性為目標(biāo)生成適當(dāng)?shù)牟渴鹪O(shè)置。如果用戶忘記致電qt_finalize_executable，則不會(huì)生成部署設(shè)置，也不會(huì)出現(xiàn)錯(cuò)誤或警告。

但是，如果用戶擺脫了打電話的負(fù)擔(dān)，那會(huì)不會(huì)很棒qt_finalize_executable？在CMake 3.19中，Qt構(gòu)建利用了新命令cmake_language(DEFER CALL)。這樣一來(lái)，就可以在定義的時(shí)間調(diào)用函數(shù)，例如，在評(píng)估當(dāng)前目錄的項(xiàng)目文件之后。

不同目錄范圍的源文件上的屬性

在某些地方，我們?yōu)槟K創(chuàng)建目標(biāo)，然后在子目錄中將源文件添加到該目標(biāo)。這樣可以使源文件的名稱與CMakeLists.txt文件保持接近。

但是，無(wú)法在這些位置指定每個(gè)源文件的屬性-我們必須進(jìn)入層次結(jié)構(gòu)的頂層才能進(jìn)行設(shè)置。我們并不經(jīng)常這樣做，但是有時(shí)在開(kāi)發(fā)過(guò)程中會(huì)出現(xiàn)這種情況，以允許根據(jù)選項(xiàng)設(shè)置在編譯時(shí)選擇實(shí)驗(yàn)功能。

在CMake 3.18中，set_source_files_properties學(xué)會(huì)了在不同目錄范圍內(nèi)設(shè)置屬性：

該DIRECTORY選項(xiàng)獲取指向處理后的源目錄的路徑的列表，并TARGET_DIRECTORY獲取目標(biāo)的列表，這些目標(biāo)的源目錄將用作設(shè)置源文件屬性的作用域列表。

get_property()并且get_source_file_property()還具有相同的新參數(shù)，除了只能指定一個(gè)值而不是列表。

add_custom_command DEPFILE支持Makefile

CMake 3.20將為Unix Makefile生成器提供depfile支持。這也是將moc生成的depfile用于Makefile的前提。

====================================================

想要了解或購(gòu)買(mǎi)Qt正版授權(quán)的朋友，歡迎

Qt技術(shù)交流群現(xiàn)已開(kāi)通，QQ搜索群號(hào)“765444821”或者掃描下方二維碼即可加入