タグ付けされた質問 「cmake」

私はGitサブモジュールの大ファンです。バージョンとともに依存関係を追跡できるので、以前のバージョンのプロジェクトにロールバックし、対応するバージョンの依存関係を安全かつクリーンに構築できます。さらに、ライブラリの履歴は、ライブラリに依存している（およびオープンソース化されない）アプリケーションの履歴とは別個であるため、ライブラリをオープンソースプロジェクトとしてリリースする方が簡単です。 仕事中の複数のプロジェクトにワークフローを設定していますが、単一のモノリシックプロジェクトではなく、このアプローチを少し極端にするとどうなるか疑問に思っていました。サブモジュールを実際に使用すると、ワームの潜在的な可能性があることにすぐに気付きました。 一対のアプリケーション：studioおよびplayer、および依存ライブラリcore、graphおよびを想定します。network依存関係は次のとおりです。 core スタンドアロンです graphcore（サブモジュール./libs/core）に依存 network上のcoreサブモジュール（サブモジュール./libs/core） studio依存graphし、network（サブモジュールに./libs/graph及び./libs/network） player依存graphし、network（サブモジュールに./libs/graph及び./libs/network） CMakeを使用しており、これらの各プロジェクトに単体テストとすべての作品があると仮定します。各プロジェクト（studioおよびを含むplayer）は、コードメトリックス、ユニットテストなどを実行するためにスタンドアロンでコンパイルできる必要があります。 事は、再帰的git submodule fetchであり、次のディレクトリ構造を取得します： studio/ studio/libs/ (sub-module depth: 1) studio/libs/graph/ studio/libs/graph/libs/ (sub-module depth: 2) studio/libs/graph/libs/core/ studio/libs/network/ studio/libs/network/libs/ (sub-module depth: 2) studio/libs/network/libs/core/ プロジェクトでcore2回複製されていることに注意してくださいstudio。このディスクスペースの浪費とは別に、core2回ビルドするため、ビルドシステムの問題が発生しますcore。 質問 共通のネストされたサブモジュールの複数のコピーを取得せずに、バージョン付きの依存関係とスタンドアロンビルドを取得できるように、サブモジュールを整理するにはどうすればよいですか？ 可能な解決策 ライブラリの依存関係がある程度示唆されている場合（つまり、「バージョンXで動作することがわかっている」または「バージョンXのみが公式にサポートされている」方法）次のシナリオを想像できます。 ビルドシステムを用意しgraph、networkどこで見つけるかを伝えますcore（たとえば、コンパイラインクルードパスを使用して）。「standalone」と「dependency」の2つのビルドターゲットを定義します。「standalone」は「dependency」に基づき、ローカルcoreサブモジュールを指すインクルードパスを追加します。 追加の依存関係を導入studioしcoreます：on 。次に、studiobuilds core、coreサブモジュールの独自のコピーへのインクルードパスを設定し、ビルドgraphしnetworkて「依存関係」モードにします。 結果のフォルダー構造は次のようになります。 studio/ studio/libs/ (sub-module depth: 1) studio/libs/core/ studio/libs/graph/ studio/libs/graph/libs/ (empty folder, …

50 git  cmake  submodules 

ですから、メイクファイルを直接作成することや、2015年にそれを行うのは馬鹿げたことです。CMakeなどのツールを知っており、実際にCMakeを頻繁に使用しています。大切なのは、CMakeはMakefileを作成して、自分でそれを行うという退屈な作業をなくすことです。もちろん、それは他の多くの素晴らしい機能を追加します...しかし、最終的にはまだMakefileです。 だから私の質問は、Makeユーティリティ全体を指すmakeに関する「時代遅れの」話ですか、それとも自分のMakefileを手動で書くというアイデアですか？私はC / C ++開発にIDEをまったく使用しません（ちょうどemacs）ので、常にMakefileを作成しました。 Makeが古いと見なされる場合、C / C ++開発者は小さな個人プロジェクトを構築するために何を使用すべきですか？

31 c++  c  builds  make  cmake 

CとC ++の世界から来たほとんどのビルドシステムには、installターゲット、特にMakefiles（たとえばGNUが推奨する場所）またはCMakeがあります。このターゲットは、オペレーティングシステム（C:\Program Files\Windowsなど）のランタイムファイル（実行可能ファイル、ライブラリなど）をコピーします。 私にとっては、プログラムをインストールすることはビルドシステムの責任ではないため（実際にはオペレーティングシステム/パッケージマネージャーの責任です）、これは非常にハッキリしています。また、ビルドシステムまたはビルドスクリプトは、環境変数、レジストリ変数、シンボリックリンク、権限などを使用して、インストールされたプログラムの構成を認識している必要があります。 せいぜい、ビルドシステムにはrelease、インストール可能なプログラム（.debまたはなど.msi）を出力するターゲットがあり、そのプログラムをインストールするようオペレーティングシステムに親切に依頼する必要があります。また、ユーザーはを入力せずにアンインストールできmake uninstallます。 だから、私の質問：ビルドシステムは通常、installターゲットを持つことを推奨するのはなぜですか？

18 build-system  cmake  make  install 

私はCMakeを使用してプロジェクトIDE / makefileを生成していますが、それでもコンパイル済みファイルを操作したり、コードを生成したりするためにカスタムの「スクリプト」を呼び出す必要があります。 以前のプロジェクトではPythonを使用していましたが大丈夫でしたが、現在作業中の2つの非常に大きなプロジェクトで多くの依存関係を管理するのが大変なため、どこでも依存関係を最小限に抑えたいと思います。 誰かが、そのための言語依存関係を追加する代わりに、C ++を使用してビルドスクリプトを作成するように私に提案しました。プロジェクトのテーマはすでにC ++を使用しているため、いくつかの利点があります。 プロジェクト全体をビルドするには、C ++コンパイラとCMakeのみが必要であり、他には何も必要ありません（他の依存関係はすべてCまたはC ++です）。 C ++の型安全性（最新のC ++を使用する場合）により、すべてが「正しく」なりやすくなります。 また、私がよく知っている言語でもあるため、優れたPythonコードを書くことができたとしても、安心して使用できます。 実行速度の潜在的な向上（ただし、実際に知覚できるとは思わない）; しかし、いくつかの欠点があるかもしれないと思うし、私はまだ試していないので、本当の影響がわからない： コードを書くのに時間がかかるかもしれません（私はC ++で十分に効率が良いのですぐに動作するものを書くので確信がないと言ったので、このシステムでは書くのにそれほど長くはないかもしれません） tこの場合は問題になります）; 入力として読み込むテキストファイルはすべてUTF-8であると想定する必要があります。実行時にC ++で簡単にチェックできるかどうかはわかりませんが、言語ではチェックされません。 C ++のライブラリは、スクリプト言語よりも管理が困難です。 私には経験と洞察力が欠けているので、長所と短所が足りないかもしれません。質問は次のとおりです。これにC ++を使用するのは理にかなっていますか？報告する経験はありますか、また重要な利点と欠点がありますか？

15 c++  builds  cmake  build-system 

単一の（git）リポジトリに保存されている一連の関連する独立したC ++プロジェクトの編成に関するアドバイスをお願いします。プロジェクトはCMakeを使用します。 簡単な例として、2つのプロジェクトAとB、Bに依存するAを想定します。Aを開発するほとんどの人は、パッケージングシステムを介してBを取得します。したがって、Aのみをコンパイルします。ただし、開発者がAとBの両方を個別にコンパイル（およびインストール）できるようにする必要があります。 これが提案です： └── Repo1 ├── CMakeLists.txt (1) ├── A │ ├── CMakeLists.txt (2) │ ├── include │ │ ├── aaa.h │ │ ├── aaaa.h │ │ └── CMakeLists.txt (3) │ └── src │ ├── aaa.cpp │ ├── aaaa.cpp │ └── CMakeLists.txt (4) ├── B │ ├── CMakeLists.txt (2) …

12 c++  organization  code-organization  dependency-management  cmake 

私の（主にC ++）開発では、長い間、ソース外ビルドの使用に固執してきました。つまり、私のソースは通常/project/srcディレクトリにあり、ビルド/project/build/bin/releaseは/project/build/bin/debugディレクトリにあります。これを行ったのは、中間ファイルからソースディレクトリをクリーンに保ち、すべてのバイナリを1か所にまとめ、パッケージ化がより簡単になり、クリーニングがより簡単になり、バージョン管理がより簡単になるからです。（私は何かを見逃しましたか？） 現在、ソース内ビルドを使用する（大きな）プロジェクトを継承しています。このタイプの構造の動機は何ですか？その利点は何ですか？（私は、エンジニアリングレベルの理由と個人的な好みのタイプの理由に最も懸念しています。） Lakosの "Large-Scale C ++ Software Design"がそれを考慮に入れてくれることを期待していましたが、そうした場合は見逃しました。

9 builds  directory-structure  large-scale-project  cmake 

したがって、私はC ++ライブラリを作成する予定であり、それをクロスプラットフォームにしたいと考えています。このライブラリはUIを処理せず、依存関係をできるだけ少なくしたいので、Qtを使用しません（実際には、Qtは私が望むものを達成するのに本当に役立ちません。使用する予定のすべてはSTLとBoostです）。クロスプラットフォームプロジェクトを構築することになると、QMakeは非常に使いやすく、経験もあるのでとても気に入っています。CMakeについても良いことを聞きましたが、QMakeほど簡単に使用できるとは思えません。 とにかく、これが私の質問です：私が知っているビルド自動化ツール、またはQMakeがQt以外のプロジェクトのコンテキスト外にあるものを使用すべきですか？これをCMakeを学ぶ機会としてとらえるべきですか？または、これら2つに代わるより良い代替手段はありますか？

9 c++  cmake