本記事は「Qt is relocatable」の抄訳です。
バージョン5.14.0以降、Qtライブラリのパスを変えることができるようになりました。つまり、機能を壊したりプラグインをロードしたりせずに、インストールしたQtを別のディレクトリに移動することができます。
WindowsプロジェクトのQtビルドマスターの役割を見てみましょう。あなたはすべての設定引数を暗記しているとしましょう。それらをどう最適化し、どの機能が不要であるかを知っています。
Qtビルドはそのプロジェクト用に完全に仕立てられており、Qtインストールを含むzipファイルを提供しています。
例えば下記を実行してみると…
configure -prefix C:/Qt/5.12.6 ...more options...
jom
jom install
zip -r X:\shared_stuff\qt-5.12.6.zip C:\Qt\5.12.6
あなたのチームメイトがアーカイブをまったく同じ場所に展開すれば、すべてが正常に機能します。
しかしここで何らかの理由により、別のデベロッパーがQtを他のドライブ/ディレクトリにインストールしなくてはならないとすると、その異なるディレクトリにあるQtは機能しません。 QMakeは正常に動作せず、プラグインもロードできず、さらにはQtアセットも見つかりません。
なぜ全てが壊れるのでしょう？
歴史的に、これまでのQtのconfigureは、インストールディレクトリをqmake実行可能ファイルとQt5Coreライブラリに焼き付けていました。 QLibraryInfoのロジックは、ハードコードされたプレフィックスの下にあるプラグイン、アセット、mkspecsを見つけようとします。これは、常に-prefix引数で設定したものでした。
もちろんです。 Qt 5.14.0以降、インストールプレフィックスは、ハードコーディングされたパスに依存することなく、Qt5Coreライブラリまたは実行可能ファイル自体の場所によって自動的に決定されるようになりました。
この自動化は、”relocatable”に設定してビルドされたQtで有効になります。
この設定は、Qtのスタティックでないビルドに対してデフォルトで有効になっています。
”relocatable”なスタティックビルドが必要な場合は、この設定を以下のように手動で有効にします。
configure -static -feature-relocatable ...
”relocatable”可能なスタティックビルドの注意点は、Qt内部の翻訳が自動的に取得されないことです。
Qtの翻訳ファイルをアプリケーションと一緒にデプロイする必要があります。
そのことが、スタティックビルドの場合に”relocatable”可能がデフォルトで無効になっている理由です。
はい、もちろんです。
configure -no-feature-relocatable ...
このようにすれば、以前の挙動に戻ります。
たとえば、Linuxディストリビューションは、”relocatable”可能なQtを必要とせず、機能をオフにすることができます。
QTBUG-14150に、この取り組みについての記録が残されています。