Qt Visual Studio Tools 的新版設定

首先，Qt VS Tools 在 Heresy 沒注意到的時候，似乎改了很多東西？以往 Heresy 使用 Qt VS Tools 建立的專案，裡面的版本設定是「Qt4VSv1.0」，而現在新建的則是「QtVS_v304」，感覺版本跳滿多的（中間有沒有其他版本個人不清楚就是了）。

而舊版的 Qt 專案，也可以透過專案右鍵選單的 Qt 子選單中，直接選擇升級（不過 Heresy 這邊有的沒有升級的選項，不知道為什麼？）。
（用自己的 build rule 建立的專案當然就不可能升級，只能重建了。）

在 Qt Visual Studio Tools 中，可以設定多個 Qt 的版本，並快速地切換，算是滿方便的～
而在建置專案的時候，系統就會去根據這邊設定的路徑，來找 Qt 相關的檔案。

在升級使用新版的 Qt 專案後，整個 build rule 應該是切換到新版去了，連同 Visual Studio 中的專案設定介面也都大改了。

以往的 Qt 相關的設定大多在另一個獨立視窗裡，現在則是好好地整合在 Visual Studio 的專案屬性裡了。

改成這樣的好處，應該就是修改設的時候的一致性更好了啦～

另外，雖然一般人應該是不用去調整，但是這邊可以設定的選項好像變更多了？不過這邊也可以看出，Heresy 當時自己撰寫的 build rule 忽略了許多東西。

之前自定義的流程

Qt VS Tools 的建置流程

Qt VS Tools 定義的建置流程，大致上會像下面的樣子：

• 把 a.ui 透過 uic 編譯成 ui_a.h
• 把 a.h 透過 moc 編譯成 moc_a.cpp
  • 這邊會 include ui_a.h
  • 在編譯時會繼續使用 cl 來編譯 moc_a.cpp
  • 並同時去編譯有使用到的檔案，包括 a.cpp（有其他檔案也會）
• 使用 cl 編譯 a.cpp
  • 這邊會 include a.h

他這樣的架構，基本上就是把透過 moc 或 rcc 產生出來的檔案，都獨立去建置；只有 uic 產生的檔案因為是圖形介面元件的類別定義，所以還是需要被引用的。

他這樣的架構確實比較好。因為之前 Heresy 自己的作法，要確保只有一個 .cpp 會 include moc_a.hpp，否則就會造成 linking 階段的重複定義（moc_a.hpp 的內容）。

不過如果是要開發函式庫的話，個人會建議不要在 a.h 裡面直接引用 ui_a.h、而是採用 forward declaration 的形式，把相關的呼叫、連同 ui_a.h 的引用都放到 a.cpp 會比較好；否則在要由外部引用 a.h 的時候，會因為要去找 ui_a.h 而產生很大的問題。

在現行的 Qt Visual Studio Tools 中，可以設定多個 Qt 的版本，並快速地切換，算是滿方便的～

而在建置專案的時候，系統就會去根據這邊設定的路徑，來找 Qt 相關的檔案。

甚至，考量到現在 Visual Studio 支援 Linux 建置（WSL 或 SSH），這邊的 Qt 平台也可以設定成 Linux 用的。

而由於 Heresy 一開始是想修改既有的 build rule 來讀取這邊的設定，所以就研究一下他到底怎麼玩的。

基本上，Qt VS Tools 是把這些版本資訊儲存在 Windows Registry 裡，他的路徑基本上是：

HKEY_CURRENT_USERSoftwareDigiaVersions

而它的內容則如下：

基本上會有「DefaultQtVersion」、儲存預設的版本；「VersionNames」則是用單一字串來記錄所有版本。

而在各版本下，基本上就是透過「InstallDir」這個字串，來儲存對應的路徑。

如果想在自己的 build rule 裡面、去取得這樣的資料的話，則可以在 .props 裡面，定義：

<PropertyGroup>
  <QtVersionsRegKey>HKEY_CURRENT_USERSoftwareDigiaVersions</QtVersionsRegKey>
  <QtVer>$([MSBuild]::GetRegistryValue('$(QtVersionsRegKey)','DefaultQtVersion'))</QtVer>
  <QTDIR>$([MSBuild]::GetRegistryValue('$(QtVersionsRegKey)$(QtVer)','InstallDir'))</QTDIR>
  <QT_INCLUDE>$(QTDIR)include</QT_INCLUDE>
  <QT_LIB>$(QTDIR)lib</QT_LIB>
</PropertyGroup>

如此一來，QtVer 就會是預設的 Qt 版本，而 QTDIR 就會是該版本 Qt SDK 的路徑了。

這樣做技術上是可以的，也就是說可以自己寫一組 custom build rule、去抓 Qt VS Tools 的設定路徑；雖然說這樣做可以自己可以在某種程度上、更有彈性地控制整個 Qt 的建制架構，但是實務上，會需要這樣的機會應該不大就是了。

由於 Heresy 這邊現在已經固定有在使用 GitLab CI/CD 來做建置，所以其實也需要研究使用 Visual Studio Build Tools 這種僅有文字介面、無法安裝 Qt VS Tools 的建置環境。

在使用舊版的 Qt VS Tools 專案的時候，基本上只需要設定「QTDIR」和「QtMsBuild」這兩個環境變數，個別去指到 Qt SDK 的安裝路徑、以及 QT VS Tools 的 build rule 所在路徑（預設是在「%LOCALAPPDATA%QtMsBuild」）就可以了。（參考）

不過在切換到新版後，光這兩個環境變數似乎就不夠用了。

Heresy 的做法，是盡量去符合 Qt VS Tools 的 build rules 的需求；所以後來是先在 Windows Registry 裡，加入相對應的版本資訊：

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USERSOFTWAREDigia]
[HKEY_CURRENT_USERSOFTWAREDigiaVersions]
"DefaultQtVersion"="QtSDK"
"VersionNames"="QtSDK"
[HKEY_CURRENT_USERSOFTWAREDigiaVersionsQtSDK]
"InstallDir"="C:\Qt\QtSDK"

然後再加入下面三個環境變數：

ENV QtInstallRegKey HKEY_CURRENT_USERSOFTWAREDigiaVersions
ENV QtInstall QtSDK
ENV QtInstallDir C:QtSDK

其中第一個 QtInstallRegKey 是告訴系統 Qt 版本的 registry 路徑，而 QtInstall 則是要使用的 Qt SDK 版本。

不過，雖然理論上之後應該會自動推論出 QtInstallDir 才對，但是由於不知道為什麼都沒辦法成功，所以後來還是連 QtInstallDir 都手動指定到對應的路徑了…

總之，這樣在加上之前的「QTDIR」和「QtMsBuild」，基本上就可以透過 MSBuild 來在命令提示字元的情況下，建置 Qt VS Tools 的專案了。