👩‍👧 ⚡️ 🥓 Qtビルドシステム：Lifebuoyのビルド 🐓 👨🏾‍🔬 👨🏼‍⚕️

注（2013年6月17日）：この記事の例の構文は、最新バージョンに対応していません。ドキュメントを確認してください。また、3月に、QBSをサポートするQt Creator 2.7がリリースされました。

少し前まで、Qt開発チームは新しいビルドシステムQBSを導入しました。もちろん、主な反応は「なぜQMAKEがあなたに合わなかったのですか？」、「CMAKEをそのまま適合させる」、「別のビルドシステム[xkcd、標準]」です。新しいシステムの約束された利点：柔軟性、すべての開発者向けの明確な構文（QMLはjavascriptのような宣言型言語です）、ビルドの速度（純粋およびインクリメンタル）、および容易な拡張性。

すでにどこかでこれをすべて聞いたことがありますので、この記事では、開発者がこのシステムにどのように来たのかを理解し、最も簡単な例を検討し、基本的な構成を調べ、現時点でIDEレベルでサポートされているものを確認します。

物語

一緒に、QBS開発者であるJörgBornemannの道をたどろうとします。

make（および派生物）に対する批判

Peter Millerによる1999年の記事は、再帰的なmakeの問題と、一般にmakefile自体の便利さを扱っています。

UNIX用の従来のUNIXビルドシステムは、大規模プロジェクト（特にインクリメンタルビルド）で許容できないほど長いビルド時間を生成します。
再帰呼び出しを使用してルートディレクトリから作成すると、モジュール間の依存関係が破壊され、アセンブリを2、3回実行する必要がなくなります（そしてもちろん、ビルド時間が長くなります）。
単一のメイクファイルを使用すると問題は修正されますが、サポートは耐えられなくなります。 IDEを使用したメイクファイルの変更に対する十分なサポートについては疑問の余地はありません。

2005年のAdrian Neaguの記事では、より一般的なmakeの問題について説明しています。

makeはそれ自体では動作しないため、makeの移植性は大幅に向上します。makefileには、プラットフォーム固有のその他の多数のユーティリティを指定できます。
再帰的なmakeを使用する場合（前の記事と同じ意見）、スケーラビリティはひどく、インクルードやその他の拡張機能を使用する場合は十分ではありません。特に、アセンブリのパフォーマンスは非常に急速に低下します。

記事「 GNU Makeの何が問題なのか」

言語のマイナス点と同じ問題については、以前と同じように詳細に説明します（繰り返しはしません）

言語の非自明で率直な欠陥のある要素（ifeq、ifneq、ifdef、ifndefのみ）
型の問題（文字列のみを使用）
コマンドラインオプションを変更するときの依存関係の解決が不十分
同時に実行と並列化の問題
プログラムを突然停止することで、アセンブリツリーを「強制終了」するのは簡単です。
また、現代のニーズには不適切なアーキテクチャを示している他の多くの小さな妨害があります（著者による）。

2007年のIan Lance Taylorによる短いメモで、Makeの代替としてのCmakeの主な欠点はHeです。多すぎる。折り畳まれた。これはいくつかの言語の地獄のような混合物であり、開発とデバッグの達人だけがそれをサポートできます（本当に複雑なシステムの場合）（デバッグするのも問題です）。もう1つの欠点は、柔軟性（FLEXIBILITYでさえ）のために、生成されたスクリプトのパフォーマンスの損失を支払う必要があることです。

QMakeの何が問題になっていますか？

Qtインフラストラクチャでは、Qmakeビルドシステムが今日広く使用されています。これは公式にサポートされており、現在も開発中です。「もう1つだけ」のシステムが必要なのはなぜですか？

Marius Storm-Olsenの記事は、次のqmakeの欠陥を分析しています。

独自の元の言語構文。

QTDIR / mkspecs / features / exclusive_builds.prfを見てください：
```
DEFINES += QT_NO_CAST_TO_ASCII !macx:DEFINES += QT_USE_FAST_OPERATOR_PLUS QT_USE_FAST_CONCATENATION unix { CONFIG(debug, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/debug-shared CONFIG(release, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/release-shared CONFIG(debug, debug|release):MOC_DIR = $${OUT_PWD}/.moc/debug-shared CONFIG(release, debug|release):MOC_DIR = $${OUT_PWD}/.moc/release-shared RCC_DIR = $${OUT_PWD}/.rcc UI_DIR = $${OUT_PWD}/.uic }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
これをすぐに理解するには、「0.5リットル」でも十分ではありません。 CMakeはこれと競合できますが。

プログラマにC ++、Pascal、Javascript、win＆unixシェル、およびSQLを知らせてください。これらの知識はすべて、ビルドシステムの習得には役に立たないでしょう。

自分から、パスの「＃」文字と$$ LITERAL_HASHの大騒ぎが多くの問題を引き起こしたと付け加えることができます（特別な言語文字をエスケープする方法を考えてみませんか？マクロをもっとよく紹介しましょう）。
IDEサポート。

Qtクリエーターはプロジェクトへの新しいファイルの追加をサポートしていますが、「通常の」構文から少し離れると、新しいHEADERSまたはFILES構造を最後に追加できます。
qmakeのアセンブリ自体の欠如。

Qmakeはプロジェクトをビルドしません。名前は誤解を招くです。 Makefileを生成するだけで、Makeユーティリティのいずれか（* nix-gnu make、win-nmake、jomまたはmingw-make）によってアセンブリが行われます。
クロスコンパイル、パッケージ構築、および展開の透過的なサポートの欠如。

最後に、Qtメーリングリストで新しいビルドシステムとその要件について説明しました。

非常に高速である必要があります（すべてのファイルのstat（）を生成するのに目立たない時間です）。

アセンブリツリーの深さのどこかでノードを変更しても、ツリー全体の構成は変更されません。
人々が簡単に理解でき、スクリプトで処理できるシンプルで理解可能な言語が必要です。

言語は十分に専門化されている必要があります。

それは、その構造において宣言的である必要があり、小さな命令型の断片があり、残りから厳密に分離されています。

言語はコマンドではなくプロパティに基づいている必要があります。 CFLAGSはありません。（cmakeを途中まで）;
モジュール性を完全にサポートする必要があります。また、サブプロジェクトは、親から簡単に分離できる（そして別のサブプロジェクトに参加できる）必要があります。つまり、大まかに言って、彼らはアセンブリの設定でフォルダを取り、それを別のプロジェクトに挿入しました-すべてもそこにうまく組み立てられています（もちろん依存関係を考慮せずに）;
IDEの明確なサポート。
1つのパスで異なるプラットフォーム用の異なる構成を構築することが可能である必要があります。

Lifebuoyの紹介-Qt Build System

2012年2月15日、JörgBornemannはQtラボでQBSプロジェクトを公開しました。現在、彼はアルファ状態ではなく、プロトタイプとアルファ版の中間にいます。正当化するために、Qt Creatorはすでにその助けを借りていると言えます。

新しいシステムを設計する基本原則：

宣言的-QML構文を使用します。
拡張性-アセンブリ用の独自のモジュールやコードジェネレーターなどを記述することが可能です（以下では、Delphiプロジェクトをアセンブルするための独自のモジュールを記述しようとします）。
スピード
直接アセンブリはqmakeではなく、「メディエーター」ではありません。 Qbs自体は、コンパイラ、リンカー、および他に必要なものを呼び出します。

まだないこと：システム構成の確認（qmakeへの要求を使用してツールチェーンを構成する）、パッケージの構築、テストの展開、そして最も重要なこと-特別なQtCreatorブランチを除くあらゆるideのサポート。

始めましょう！

著者はソースから qbsをビルドすることを勧めていますが、winおよびlinuxユーザー用のバイナリアセンブリがあることを覚えておいてください。

win-MSVC2010で構築されました。また、gitからバージョンを作成することをお勧めします（プラグインとMOCに問題がありました）。

バイナリ形式では、qbsはQtCoreおよびQtScriptライブラリに依存します（+ Qt5の同時接続）

C ++でHello Worldプロジェクトを作成しましょう。

main.cpp

 #include <iostream> using namespace std; int main() { cout << "Hello world!" << endl; return 0; }

また、最小限のqbsプロジェクトを作成します。

hello.qbp

 import qbs.base 1.0 CppApplication { name: "HelloWorld" files: "main.cpp" }

Linux：

1.現在のフォルダーでシェルを開きます。

2. qbsを解凍/収集したパスをPATH（または、binフォルダー）に追加します

PATH =〜/ qbs / bin /：$ PATH

3. qbsの起動：

qbs

 Found project file /home/mapron//example-3/hello.qbp loading project took: 69 ms build graph took: 18 ms for debug: - [hpp, application] HelloWorld as debug compiling main.cpp linking HelloWorld Build done.

その後、ビルドプログラムはプロジェクトの分析を開始し、ビルド/デバッグフォルダーに実行可能ファイルを収集します（まあ、宛先フォルダーをまだ指定していませんか？）

WINDOWS：

4. Windowsでは、原則として、コンパイラとqtがPATHにないため、qbsは「 qbs platform probe 」の実行を要求する場合がありますが、これは実行する必要があります。

5.次に、 qbs config updateなどを実行する必要がある場合があります（要求された場合、すでに修正されている可能性があります）。

6.その後、 qbs [build]が起動すると、アセンブルされたバイナリ「HelloWorld.exe」が取得されます。

私たちは勉強を続けます

それでは、もっと複雑なもののアセンブリをマスターし、同時に言語に対処してみましょう。

まず、新しいフォルダーを作成し、そこにQtがあるexamplesフォルダーから「 2dpainting 」および「 collidingmice 」フォルダーをコピーします。

なぜ一度に2つですか？ 2つの製品を一度に組み立てるための構成を作成します。

製品は、ビルドシステムのターゲット「出口」であり、Qmakeをビルドするときの「.pro」ファイルに似ています。 1つのqbsプロジェクトに複数の製品を含めることができます。

最初に、「 examples.qbp 」プロジェクトを作成します

 //     QML import qbs.base 1.0 import qbs.fileinfo 1.0 as FileInfo Project { //    - . moduleSearchPaths: "qbs" //     ,   cpp  qt //        -   . Product { name: "2dpainting" //    ( ,    ) type: "application" //  - , ..  . Depends { name: "cpp" } //      C++ Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } //  Qt  QtCore, QtGui, QtOpengl files: [ //     .    ,  . "2dpainting/glwidget.h", "2dpainting/helper.h", "2dpainting/widget.h", "2dpainting/window.h", "2dpainting/glwidget.cpp", "2dpainting/helper.cpp", "2dpainting/main.cpp", "2dpainting/widget.cpp", "2dpainting/window.cpp", ] } }

コンソールを開いて、ビルドしようとすると、エラー「エラー：ビルド環境のセットアップ中にエラーが発生しました：qt.core.incPathが設定されていません。プロファイルでqt.core.incPathまたはqt.core.pathを設定します。」

とりあえず 、あまりユーザーフレンドリーではない設定方法に目を向け、次の内容（WINDOWS）でファイル「 qbs.config 」を作成します。

 modules.qbs.platform: MSVC2010 profile: default profiles.default.qt.core.path: C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/

LINUX（ubuntu）の下で：

 modules.qbs.platform: gcc profile: default profiles.default.qt.core.binPath: /usr/bin/ profiles.default.qt.core.libPath: /usr/lib/qt4 profiles.default.qt.core.incPath: /usr/include/qt4 profiles.default.qt.core.mkspecsPath: /usr/share/qt4/mkspecs

qbs config --import qbs.config

を実行します

その後、qbsは通常、プロジェクトをビルドし、出力ファイルをbuild / debugフォルダーに配置できます。

リリース用のプロジェクトをビルドするには、 qbs build releaseを実行します。

すべてのビルドファイル（つまり、ビルドフォルダー）をクリーンアップするには、 qbs cleanを実行します。

次に、2つのプロジェクトの拡張可能な構造を整理してみましょう。「 2dpainting 」および「 collidingmice 」サブディレクトリで、次の内容の拡張子「.qbs」を使用して、ディレクトリの同名ファイルを作成します。

 import qbs.base 1.0 Product { name: "2dpainting" type: "application" Depends { name: "cpp" } Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } files: [ //     ,    . "glwidget.h", "helper.h", "widget.h", "window.h", "glwidget.cpp", "helper.cpp", "main.cpp", "widget.cpp", "window.cpp", ] }

 import qbs.base 1.0 Product { name: "collidingmice" type: "application" Depends { name: "cpp" } Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] } files: [ "mouse.h","main.cpp", "mouse.cpp" ,"mice.qrc"] }

つまり並行してビルドできる独立した製品にコードを分割します。 examples.qbpに変更を加えます。

 //     QML import qbs.base 1.0 import qbs.fileinfo 1.0 as FileInfo Project { //    - . moduleSearchPaths: "qbs" //        -   . //      references. :     ! //     ,    references: [ "2dpainting/2dpainting.qbs", "collidingmice/collidingmice.qbs", ] }

qbsを再度実行できます。「.qrc」ファイルの場合、「rcc」が自動的に呼び出され、これらすべてがリンクされます。この場合、qmakeの場合のように、すべてのファイルが1つのリストで示され、HEADERS、SOURCESなどに分離されません。

どのように機能しますか？

手始めに、ヘルプをざっと見ておくことをお勧めします

言語の主な概念：プロジェクト、製品、製品、アーティファクト、モジュール、ルール、グループ、依存、タグ。

製品は、proまたはvcprojの類似物、つまりアセンブリの1つのターゲットです。

プロジェクトとは、ビルドシステム全体で認識される依存関係を伴う製品のセットです。 1つのプロジェクト-1つのビルドグラフ。

タグはファイル分類システムです。たとえば、「* .cpp」=>「cpp」

ルール-特定のタグでマークされたプロジェクトファイルを変換します。アーティファクトと呼ばれる他のファイルを生成します。通常、これらはコンパイラまたはその他のビルドシステムです。

アーティファクトとは、ルールの出力（および場合によっては他のルールの入力）であるファイルです。これらは通常、「obj」、「exe」ファイルです。

多くのQMLオブジェクトには、アセンブルするかどうかを制御する条件プロパティがあります。そして、そのようなファイルを分割する必要がある場合は？これを行うには、それらをグループにまとめることができます（グループ）

 Group { condition: qbs.targetOS == "windows" files: [ "file1", ...] }

このようなもの。

次は？

論理的な質問、例は素晴らしいですが、このシステムでどうやって自由に泳ぐことができますか？次のことができます。

ドキュメントを読んでください。
Qt Creatorのソースをダウンロードして、そこでQBSがどのように使用されているかを確認してください。
QBS自体のソースコードを学習します（緊急の場合）。

おわりに

QBSには次の利点があります。

便利で明確なアセンブリ構成形式
高速
明確なモジュラーアーキテクチャ

しかし、残念ながら、次のようなものがあります（一時的な欠点）

多数のバグの存在（これはアルファではありません）。
IDEのサポートの欠如（Qt Creatorで待機）;
パッケージアセンブリシステムの不足、インストーラー（計画中）。

残念ながら、この記事の形式では、トピックを明らかにする将来の計画で、すべての詳細を明らかにすることはできません。

独自のモジュールを作成します（サンプルと共にアーカイブに含まれています）。
アセンブリのルールを作成します。
js-modulesの作成とそれらの包含;
独自のタイプの製品を作成します。
グローバル構成とモジュール構成を操作します。
独自のプラグインの作成（.drpojファイルの依存関係の解析用）。

このすべてはこの記事に記載されており、コメントに何かが書かれています。

記事へのすべての例を含むアーカイブへのリンク：

narod.ru/disk/49759080001.18d6748f8ef86e26c6dea2e2c5ed7d13/examples.zip.html

アーカイブされたボーナス！記事に記載されていないDELPHI 2007プロジェクトを組み立てるためのモジュールの例（次の記事で解析する予定です）。

参照資料

labs.qt.nokia.com/2012/02/15/introducing-qbs-表示

doc-snapshot.qt-project.org/qbs-ドキュメント

qt.gitorious.org/qt-labs/qbs-git

bugreports.qt-project.org/browse/QBS-バグトラッカー。

注：Qt Build Salvationは、READMEソースツリーのQBSの内部名です。

Qtビルドシステム：Lifebuoyのビルド

物語