入力するものとC ++プロジェクトをアセンブルする方法

この質問を聞いて、私はまず要件を定式化しました：アセンブリシステムとグラフィカル開発環境のための厳格でオプションの（しかし望ましい）。

AndroidやQtのようなフレームワークなどの特定のプラットフォーム用のC ++コードを書くことではなく、コードの構築と編集の両方で準備ができているのではなく、特定のプラットフォームに関連付けられていない汎用コードまたはフレームワークに。

全般：

• 無料です。
• クロスプラットフォーム（少なくともWindowsおよびLinux）。

ビルドシステム：

• 異なるプラットフォームで構築する単一のチーム。
• すべての依存関係を適切に考慮したインクリメンタルアセンブリ：ヘッダーファイルとアセンブリに使用されるサードパーティコンポーネント。
• アセンブリスクリプトには、特定のプロジェクトに固有の必要な最小構成のみを含める必要があります。 ビルドの一般的なロジックは、スクリプトからスクリプトへと移動するべきではありませんが、ビルドシステムまたはそのプラグインにあります。
• 組み込みの並列アセンブリ。
• さまざまなツールチェーン（少なくともgcc、Visual C ++、CLang）のサポート。
• ビルドスクリプト全体を書き換えることなく、最小限のコストでツールチェーンを変更する機能。
• 簡単に切り替え可能なビルドオプション：デバッグとリリース。
• makeなどの追加の低レベルツールへの依存は、完全に望ましくありません。 つまり、アセンブリシステムは自給自足でなければなりません。
• JVM用のpkg-configやMaven Centralなどのサードパーティコンポーネントのリポジトリとビルドシステムを統合することは非常に望ましいことです。
• ビルドシステムは、次のようにプラグインによって拡張可能である必要があります。 特定の各プロジェクトのビルド手順は、標準の構築コンセプト（たとえば、コード生成、または非標準イメージのアセンブリ）よりも複雑になる場合があります。
• ビルドスクリプトが何らかの高レベルプログラミング言語またはより優れたDSLである場合に便利です。 これにより、非常にコストがかからず、スクリプト内で直接構造の動作を明示的に変更できます。
• ビルドスクリプトからコンパイラとリンカを設定するとき、システムが少なくとも基本的な抽象化を提供する場合、それは非常に便利です。たとえば、マクロを追加したい-なぜ、どのコンパイラコマンドラインパラメータがこれに関与するかを考えますか？ MSVCの/ Dまたはgccの-D-これらの重要でない詳細をビルドシステムに自動的に解決させます。
• グラフィカル開発環境（IDE）との良好な統合。

IDE：

• IDEがC ++コードを正しく「理解」する能力。 IDEは、すべてのプロジェクトファイルと、すべてのサードパーティおよびシステムのヘッダーファイルと定義（定義、マクロ）のインデックスを作成できる必要があります。
• IDEは、プロジェクトをビルドするためのコマンドをカスタマイズする機能、およびヘッダーファイルと定義を検索する場所を提供する必要があります。
• コードの入力に効果的に役立つはずです。 最適な補完オプションを提供し、構文エラーなどについて警告します
• 大規模なプロジェクトをナビゲートするのは便利で、使用方法をすばやく簡単に見つけることができます。
• 名前変更など、リファクタリングのための十分な機会を提供します。
• テンプレートコードを生成する機能も必要です-新しいクラスフレームワーク、ヘッダーファイル、実装ファイルを作成します。 ゲッター/セッターの生成、メソッド定義、オーバーロード仮想メソッド、純粋に仮想クラス（インターフェース）の実装パターンなど
• Doxygenなどのコードドキュメントタグの強調表示とサポート。

これらの「ウィッシュリスト」に照らして、いくつかのアセンブリシステムとグラフィカル開発環境を検討しました。 この短いレビューは完全なふりをするものではなく、私の主観的な評価を含んでいますが、おそらく最初のステップとして有用な誰かに思われるでしょう。



作る - [古代]マストドンであり、誰もが引退したくないが、ますます多くの新しいプロジェクトを引き受けることを余儀なくされるアセンブリシステムの当然のベテランです。 これは、独自の特定の言語を備えた非常に低レベルのツールであり、タブではなくスペースを使用すると、その場で実行するとすぐに脅かされます。 makeを使用すると、任意の複雑なビルドを行うことができますが、スクリプトを作成する努力を払って、それを最新に保つ必要があります。 ビルドのロジックをプロジェクトからプロジェクトに移すのも費用がかかります。 忍者やジャムなどの最新の化粧代替品がありますが、本質は変わりません-これらは非常に低レベルのツールです。 アセンブラと同じように、好きなものを書くことができますが、それだけの価値はありますか？



CMake- [Middle Ages]メイクの低レベルの詳細から逃れるための最初の試み。 しかし、残念ながら、そこまで行くことはできませんでした。ここでのエンジンは、CMakeがより高レベルのビルド記述を持つ別のテキストファイルに基づいて巨大なメイクファイルを生成するものと同じメイクです。 Qmakeも同様に機能します。 このアプローチは、新鮮なプラスチックで慎重に覆われた古い木造住宅の美しい外観を思い出させます。 CMakeは安定した実績のあるシステムであり、Eclipseとの組み込み統合もありますが、残念ながら、記事の冒頭で述べた要件の一部と矛盾するため、私には向いていませんでした。 Linuxでは、すべてがうまくいくように見えますが、MSVCを使用してWindows上で同じプロジェクトをビルドする必要がある場合-そして、MinGWよりもネイティブコンパイラを好む場合、NMakeのファイルが生成されます。 つまり 別のツールへの依存関係および別のプラットフォーム用の異なるビルドコマンド。 そして、これらのすべては、他の「ヘルパー」によって作業の大部分が行われるとき、少し曲がったアーキテクチャの結果です。



Ant- [ルネッサンス] Java用のmakeの一種のクローン。 率直に言って、C ++のビルドシステムとしてAnt（およびMaven）をチェックするのにかなりの時間を費やしました。 そして、ここでのC ++サポートは純粋に「ショー」であり、十分に開発されていないという感触をすぐに感じました。 さらに、Javaプロジェクトでも、Antはほとんど使用されていません。 スクリプト言語（およびMavenの場合）として、ここでXMLが選択されています-この下劣な鳥の言語:)。 この楽観的な事実は、このトピックにさらに没頭するために私をまったく追加しませんでした。



SConsは、 （新しい時代の） Pythonで書かれた自己完結型のクロスプラットフォームビルドシステムです。 SConsは、JavaビルドとC ++ビルドの両方で同様にうまく機能します。 インクリメンタルアセンブリのヘッダーの依存関係は正しく機能し（理解しているとおり、ビルドメタデータを使用して特定のデータベースが作成されます）、Windows MSVCではタンバリンなしで動作します。 ビルドスクリプト言語はPythonです。 非常に価値のあるシステムであり、私はその研究を終わらせたいと思っていましたが、ご存知のように、完璧に制限はなく、より詳細な調査により、上記の要件に照らしていくつかの欠点が明らかになりました。



コンパイラの抽象的な設定はないため、たとえば、ツールチェーンを変更する必要がある場合は、ビルドスクリプト内の場所を探して変更を加える必要があります。 同じマクロをネストされた条件で記述する必要があります-Windowsの場合はGCCの場合など。



リモートのアーティファクトと、あるビルドが別のビルドに高度に依存することはサポートされていません。



一般的なアーキテクチャは、いわゆるユーザー定義ビルダーがほぼ分離して存在するように構築されており、既存のビルドロジックを使用して、単純なプラグインを介して独自のビルドロジックを補完する方法はありません。 しかし、全体的には小規模なプロジェクトにふさわしい選択です。



Gradle [現在] -Gradle for JavaおよびKotlinプロジェクトを使用したことで、前向きな経験があり、それに対する大きな希望がありました。



JVM言語の場合、Gradleには、プロジェクトのビルド（ビルドの依存関係）に必要なライブラリを操作するという非常に便利な概念があります。

• このスクリプトは、リポジトリのアドレスをアーティファクト、たとえばmavenまたはivyに登録します。 また、他のタイプ/形式のリポジトリにすることもできます-プラグインのみが存在する場合。 リモートリポジトリ、Maven Central、またはネットワーク上のどこかでホストしている個人ホスト、またはファイルシステム上の単なるローカル担当者です。
• また、スクリプトの特別なセクションでは、ビルドの依存関係が直接示されています-必要なバイナリアーティファクトとバージョンのリスト。
• ビルドを開始する前に、Gradleはすべての依存関係を解決しようとし、すべてのリポジトリで指定されたバージョンのアーティファクトを探します。 バイナリはキャッシュにロードされ、ビルドに自動的に追加されます。 これは非常に便利で、C ++の場合、おそらく似たようなことをしたいと思っていました。

最初に、C ++サポートの「古い」プラグイン-「cpp」をチェックアウトし、失望しました-スクリプト構造は直感的ではありません：モデル、コンポーネント、nativespec-さまざまなタイプのバイナリからのある種のミッシュマッシュ：実行可能ファイルとライブラリの両方がすべて1つのスクリプトに含まれています。 単体テストをどこに置くかは明確ではありません。 この構造は、Javaで使用したものとは大きく異なりました。



しかし、C ++サポート用の「新しい」プラグインもあることが判明しました。`cpp-application`-アプリケーション用、 `cpp-library`ライブラリ用：静的および動的、そして最後に` cpp-unit-test`ユニットテスト用。 そして、それが私が探していたものでした！ :)



デフォルトのプロジェクトフォルダー構造は、Javaプロジェクトに似ています。

• src / main / cpp-メイン* .cppプロジェクトファイルのルートフォルダー。
• src / main / headers-内部ヘッダーファイルのフォルダー。
• src / main / public-エクスポートされたヘッダーのフォルダ-ライブラリ用。
• src / test / cpp-テストユニットの* .cppファイルのフォルダー。

このような構造は厳格ではありません。スクリプトでいつでも変更できますが、特別な必要がない限りこれを行うことはできません。非常に合理的です。



ちなみに、ビルドスクリプトは通常build.gradleです 。これらは、選択するGroovyまたはKotlinのDSL（ build.gradle.kts ）です。 スクリプト内では、Gradle APIとスクリプトに追加されたプラグインのAPIは常に利用可能です。



ライブラリの場合、タイプを選択できます：静的または動的（または両方のオプションを収集）。

デフォルトでは、Debug（ gradle assemble ）とRelease（ gradle assembleRelease ）の2つのビルドオプションが構成されています。



単体テストの実行原理はJavaの場合と同じです：gradleテストはメインコンポーネントをビルドし、次にsrc / test / cppフォルダーにある場合はテストをビルドしてから、テストアプリケーションを実行します。



悪名高い定義は抽象的な方法で設定できます-Gradle自体が必要なコンパイラオプションを生成します。 最適化、デバッグ情報など、さらに抽象的な設定がいくつかあります。



すぐに使用できるGCC、Microsoft Visual C ++、CLangがサポートされています。



プラグインシステムは非常に開発されており、拡張アーキテクチャは便利です。既製のロジックを使用して、それを装飾/拡張できます。 プラグインには2つのタイプがあります。動的プラグインは、Groovyで直接記述され、スクリプトに埋め込まれるか、Java（またはJVMを使用する別の言語）で記述され、バイナリアーティファクトにコンパイルされます。 プラグインには、誰でもプラグインを投稿できる無料のGradleアーティファクトがあり、誰でも利用できます。 これはこの記事の著者によって成功裏に完了しました:)が、それについては後で詳しく説明します。

Gradle for C ++でバイナリコンポーネントを操作するシステムについて説明します。Javaとほぼ同じです。 依存関係のビルドは、上記で説明したものとほぼ同じように機能します。



例として複合ビルドを取り上げます。

• utils-ライブラリフォルダー
• appは、utilsを使用するアプリケーションのあるフォルダーです。
• settings.gradle-これら2つのコンポーネントを複合ビルドに結合するためのGradleファイル。

appフォルダーのbuild.gradleファイルに、次の依存関係を記述するだけで十分です。

dependencies { implementation project(':utils') }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Gradleが残りを行います！ コンパイラへのパスを追加して、utilsヘッダーファイルを検索し、ライブラリbinarをリンクします。



そして、これはすべてLinux GCCとWindows MSVCの両方で同様にうまく機能します。

もちろん、インクリメンタルビルドもうまく機能します。utilsのヘッダーを変更すると、アプリが再構築されます。



判明したように、Gradleはさらに進んで、C ++アーティファクトをMavenリポジトリにアップロードする機能を実現しました！ これを行うには、標準の `maven-publish`プラグインを使用します。



スクリプトでは、アーティファクトを配置し、gradleを公開する（またはローカル公開の場合はgradle publishToMavenLocal）リポジトリを指定する必要があります。 Gradleはプロジェクトを停止し、

バージョン、プラットフォーム、アーキテクチャ、ビルドオプションを考慮して、特別な形式でレイアウトします。



バイナリライブラリファイル自体とパブリックヘッダーファイルは、 src / main / publicフォルダーからレイアウトされます。



C ++アーティファクトをMaven Centalにアップロードできないことは明らかです。必須のシステムチェックに合格しません。 しかし、ネットワーク上のMavenリポジトリを上げることはまったく難しくなく、ローカルリポジトリに対して何もする必要はありません-それはディスク上の単なるフォルダです。



プロジェクトで誰かのライブラリを使用したい場合は、ビルドスクリプトで次のように記述できます。

  repositories { maven { url = 'https://akornilov.bitbucket.io/maven' } } unitTest { dependencies { implementation 'org.bitbucket.akornilov.tools:gtest:1.8.1' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ユニットテストには、 Mavenリポジトリの gtestアーティファクトバージョン1.8.1を使用する必要があると書かれています 。



ちなみに、これは非常にリアルなリポジトリで、WindowsおよびLinux x86_64のGradleを使用してビルドされたテストビルドGoogle Test v1.8.1が投稿されています。



当然、Gradleの外部コンポーネントと連動するようにコンパイラーとリンカーを構成する際の低レベルの作業はすべて引き継がれます。 そのようなリポジトリを使用して、そのようなライブラリを使用する意思を宣言するだけで十分です。



IDEとの統合のために、GradleにはVisual StudioとXcode用の2つの組み込みプラグインがあります。 Visual Studioプラグインがsrc / test / cppフォルダーからのユニットテストコードを無視し、メインコードのみのプロジェクトを生成することを除いて、それらはうまく機能します。

IDEについて、そしてGradleと友達を作る方法について話します。

Eclipse CDT（2018-12R）は、成熟した高品質の製品です。 彼があなたのプロジェクトをうまく解析できたなら、あなたは幸運です-編集するのは快適でしょう。 おそらく、彼は最も混乱したタイプの自動車さえ「理解」するでしょう。 しかし、そうでない場合...その後、彼は赤い点線で連続してすべてを激しく強調し、悪い言葉で誓います。 たとえば、標準のMSVCおよびWindows SDKヘッダーファイルをダイジェストしません。 完全に無害なprintfでさえ、赤い点線で下線が引かれており、意味のあるものとして認識されていません。 std :: stringもありました。 Linuxのもとでは、彼のネイティブgccですべてがうまくいきます。 しかし、姉妹のAndroid Nativeからプロジェクトのインデックスを作成しようとしても、問題が始まりました。 バイオニックヘッダーでは、彼は、size_tの定義、および同時にそれを使用したすべての関数の参照を拒否しました。 おそらく、Windowsでは、たとえばMicrosoftヘッダーファイルの代わりにCygwinまたはMinGW SDKを使用して、状況を修正することができますが、これらのトリックは私にはあまり興味がありません。私はこのレベルのソフトウェアが「与えるものを食べる」だけでなく、彼が「愛する」こと。

テンプレートコードのナビゲート、リファクタリング、および生成の可能性は素晴らしいですが、文字を入力する際に​​ヘルパーに質問があります：長い名前からいくつかの文字を入力して、補完オプションを提供してみませんか？ いいえ、アシスタントはユーザーがアクセスするまで辛抱強く待ちます。 または->または::。 私は常にCtrl +スペースを押す必要があります-迷惑です。 Javaでは、CDTのアルファベット全体をトリガーとして選択することにより、この厄介な欠陥を修正できましたが、簡単な解決策は見つかりませんでした。











NetBeans 8.1 / 10.0-私はこのIDEをJavaに使用していましたが、必要な機能をすべて備えた優れた軽量のソフトウェアとして記憶されていました。 C ++の場合、コミュニティではなく、NetBeansによって直接開発されたプラグインがあります。 C ++プロジェクトの場合、makeとgccにはかなり厳しい依存関係があります。 コードエディターはのんびりしています。 テンプレートコードジェネレーターには非常に単純なものは見つかりませんでした：クラスヘッダーファイルに新しいメソッドを追加します-メソッド本体をcppファイルに生成する必要があります-方法はわかりません。 コードの「理解」の程度は平均であり、何かが解析されているように見えますが、そうではないようです。 たとえば、自動反復子を使用してマップを反復処理することは、彼にとってすでに困難です。 Google Testのマクロは誓います。 ビルドコマンドのカスタマイズには問題があります-gccを使用してLinuxを使用可能にする（これは別のビルドシステムが既に使用されているという事実にもかかわらず）が動作し、WindowsではMinGWを必要としますが、実行しても、ビルドを拒否します。 一般に、C ++を使用してNetBeansで作業することは可能ですが、それを快適とは呼びません;さまざまな痛みに気付かないように、この環境を本当に愛する必要があるでしょう。











KDevelop 5.3.1-かつてKDE（Linux）の開発者ツールとして考えられていましたが、現在はWindows用のバージョンがあります。 美しい構文強調表示（Kateに基づく）を備えた高速で楽しいコードエディターがあります。 左のビルドシステムを改ざんすることはできません。メインビルドシステムはCMakeです。 MSVCおよびWindows SDKヘッダーに耐性があります。いずれの場合も、printfおよびstd :: stringは、Eclipse CDTのような混乱を引き起こしません。 コードを書くための非常に迅速なヘルパー-入力中にほぼすぐに良い補完オプションを提供します。 テンプレートコードを生成する興味深い機会があります。独自のテンプレートを作成し、それをオンラインにすることができます。 テンプレートから作成する場合、既製のテンプレートのデータベースに接続して、好きなテンプレートをダウンロードできます。 動揺した唯一のこと：新しいクラスを作成するための組み込みテンプレートは、WindowsとLinuxの両方で曲がって動作します。 クラスを作成するためのウィザードには、多くの項目を構成できるウィンドウがいくつかあります。どのコンストラクターが必要か、クラスのメンバーなど。 しかし、Windowsの最終段階では、ある種のエラーが時間内にポップアップし、そのテキストが不可能であり、2つのファイルhとcppが1バイトのサイズで作成されます。 Linuxでは、何らかの理由でデザイナーを選択できません。タブは空で、ヘッダーファイルのみが出力で正しく生成されます。 一般に、このような成熟した製品の小児期の病気は、なんとなく軽薄に見えます。











QtCreator 4.8.1（オープンソース版） -おそらく、この名前を聞いたあなたは、このモンスターがフック付きギガバイトディストリビューションキットでQtの下に投獄されたことに困惑しているでしょう。 しかし、これは汎用プロジェクト用の環境の「ライト」バージョンです。 その配布キットの重量は約150 MBであり、Qtに固有のもの（ download.qt.io/official_releases/qtcreator/4.8）は含まれていません。

実際、彼は私の要件で私が書いたほとんどすべてを迅速かつ正確に行うことができます。 WindowsとLinuxの両方の標準ヘッダーを解析し、ビルドシステムに合わせてカスタマイズし、補完オプションを提案し、新しいクラス、メソッド本体を便利に生成し、リファクタリングとコードナビゲーションを可能にします。 この問題やその問題を克服する方法を常に考えずに快適に仕事をしたいだけなら、QtCreatorを見るのは理にかなっています。











実際、Gradleで完全に機能するのに十分ではなかったもの、つまりIDEとの統合についてはまだ話がありません。 システムがIDE自体のプロジェクトファイルを生成するには、プロジェクトをビルドするためのコマンドがすでに書き込まれ、すべてのソースファイルがリストされ、ヘッダーファイルを検索して決定するためのパスが必要です。



この目的のために、 Gradle `cpp-ide-generator`のプラグインを作成し、Gradleプラグインポータルで公開しました。



プラグインは、「cpp-application」、「cpp-library」、および「cpp-unit-test」でのみ使用できます。

build.gradleでの使用例を次に示します。

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-ide-generator' version '0.3' } library { // Library specific parameters } // Configuration block of plugin: ide { autoGenerate = false eclipse = true qtCreator = true netBeans = true kdevelop = true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラグインは、上記のすべてのグラフィカル開発環境との統合をサポートしていますが、プラグイン構成ブロックで-ide、不要なIDEのサポートを無効にできます。

  kdevelop = false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

autoGenerateパラメーターが trueに設定されている場合、許可されているすべてのIDEのプロジェクトファイルがビルド中に自動的に生成されます。 また、自動生成モードでは、ビルドがクリーンアップされるとプロジェクトファイルが削除されます： gradle clean 。



増分生成がサポートされています。 実際の更新が必要なファイルのみが更新されます。



プラグインが追加する目標のリストは次のとおりです。

• generateIde-許可されているすべてのIDEのプロジェクトファイルを生成します。
• cleanIde-許可されているすべてのIDEのプロジェクトファイルを削除します。
• generateIde [name]-指定された名前（IDEが許可されている必要があります）でIDEのプロジェクトファイルを生成します（例：generateIdeQtCreator）。
• 利用可能な名前：Eclipse、NetBeans、QtCreator、KDevelop。
• cleanIde [name]-指定された名前のIDEのプロジェクトファイル（cleanIdeQtCreatorなど）を削除します。

生成中、プラグインはビルドを「スニッフィング」し、プロジェクトファイルを作成するために必要なすべての情報をそこから抽出します。 プロジェクトを開いた後、すべてのソースファイルがIDEに表示され、すべてのヘッダーへのパスが登録され、構成/ビルド/クリアの基本的なビルドコマンドも構成されます。



私がしなければならなかった2番目のプラグインは`cpp-build-tuner`と呼ばれ、cpp-application`、` cpp-library`および `cpp-unit-test`と連携して動作します。



プラグインには設定がありません。アップロードするだけで十分です。

  plugins { id 'cpp-library' id 'maven-publish' id 'cpp-unit-test' id 'org.bitbucket.akornilov.cpp-build-tuner' version '0.5' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプラグインは、さまざまなビルドオプション（デバッグとリリース）のツールチェーン（コンパイラーとリンカー）の設定で小さな操作を実行します。 MSVC、gcc、CLangがサポートされています。



これは特にMSVCに当てはまります。リリースビルドの結果、デフォルトではbazhdash情報と静的にリンクされた標準ライブラリを備えた美的ではない「太字」が得られるためです。 Visual Studio自体のMSVCの設定の一部を「スパイ」しました。デフォルトでは、C ++プロジェクトに追加されます。 gcc / CLangとMSVCの両方について、リンク時間の最適化がリリースプロファイルに含まれています。



注：プラグインは、Gradle v5.2.1の最新バージョンでテストされており、以前のバージョンとの互換性についてはテストされていません。



プラグインのソースコード、ライブラリにGradleを使用する簡単な例：静的および動的、およびそれらを使用するアプリケーションを表示できます： bitbucket.org/akornilov/tools next gradle / cpp。



この例では、単体テストライブラリにGoogle Testを使用する方法も示しています。



Gradleに組み込まれたGoogle Test v1.8.1を使用したMavenリポジトリー（モックなし）。



UPD：



QtCreato rのWindowsバージョン4.6.2よりも古い（少なくともこれらの行を書いている時点では、最大4.10まで）MSVC SDKを理解する「忘れられた方法」があります。 すべてのstd ::スペースは赤で下線が引かれ、索引付けを拒否します。 したがって、現時点では、バージョン4.6.2はWindowsでの作業に最適です。



cpp-build-tuner



tuner v1.0プラグインの新しいバージョンがリリースされました（ cpp-ide-generator



v0.5はマイナーな改善です）。

1） cpp-build-tuner



構成ブロックを追加しました。

 buildTuner { lto = false gtest = '1.8.1' libraries { common = ['cutils.lib'] windows = ['ole32', 'user32'] linux = ['pthread', 'z'] } libDirs.common = ['../build/debug', '../release'] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

lto （boolean）-リリースビルドのLTOを有効または無効にします。 デフォルトで有効になっています。



gtest （文字列）-単体テストのGoogleテストサポートを追加します。 現在、バージョン1.8.1のみがGCC、MinGW-W64、およびMSVCでサポートされています。



ライブラリ （コンテナ）-リンクするライブラリのリスト。 コンテナ内には3つのフィールド（行のリスト）があります： common



-任意のプラットフォーム用のライブラリ、 windows



-Windowsおよびlinux



のみlinux



のみ。



libDirs （コンテナ）-リンカでライブラリを検索するためのフォルダのリスト。 コンテナ構造は、ライブラリリストと同じです。



2） cpp-application



アプリケーションを実行する機能が追加されました。 プラグインは、このためにプロジェクトに追加のタスクを追加します： run



、 runDebug



（ run



と同じ）およびrunRelease



。 タスクはassembleRelease



それぞれassemble



、 assembleDebug



およびassembleRelease



依存します。

標準の「Javaアプリケーションプラグイン」と同様に、起動時にコマンドラインパラメーターを渡すことができます： gradle run --args="arg1 arg2 ..."



。



UPD



ホスティングプラグインの変更に関連して、グループが変更されました。

 plugins { id 'loggersoft.cpp-build-tuner' version '1.1' id 'loggersoft.cpp-ide-generator' version '0.5' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいプロジェクトのアドレス： gradle-cpp.sourceforge.io



ドキュメント：

sourceforge.net/p/gradle-cpp/wiki/cpp-build-tuner

sourceforge.net/p/gradle-cpp/wiki/cpp-ide-generator