現在、Code::Blocks に関する中規模/大規模プロジェクトに取り組んでおり、ファイルをどのように整理すればよいか悩んでいます。
まず、Code::Blocks で「仮想フォルダー」を作成するのは非常に自然なことのようですが、ディスク上では、すべてのファイルがプロジェクトのルート フォルダーにあり、私にとっては面倒に思えます: コードの外で何かをしたい場合: :ブロック、ファイルを見つけるのは困難です。とにかくこの方法を使用する必要がありますか?
次に、必要になるたびに「実際の」フォルダーを作成する場合は、それらを作成するためにパスに追加する必要があります。さらに、Code::Blocks はそれを好まないようです。Code::Blocks に「ルート プロジェクト ディレクトリの直下にあるプロジェクト ディレクトリのサブフォルダにファイルがあるかのようにプロジェクトをビルドする」と言う簡単な方法はありますか?
プロジェクトが通常 Code::Blocks でどのように編成されているか、インターネット上で見つけられませんでした。リンクは歓迎します。
新しいプロジェクトを作成する場合、新しいソフトウェア アプリケーションをコーディングする場合、または既存のコードをリファクタリングする場合は、プロジェクトを適切に構成することをお勧めします。構造化にはおそらく何百もの方法があり、考慮すべきことはたくさんありますが、ここでは、私にとって本当に何度もうまくいった可能なアプローチを 1 つ紹介したいと思います。この例/提案は、このトピックに関して私が行った長年の研究の要約であるため、単なる「アイデア」ではありません
プロジェクトを編成する際に必ず対処しなければならない「主な」問題が 3 つあります。
すべてのプロジェクトは言うまでもなく、中規模から大規模のプロジェクトは、バージョン管理する必要があります(例として GIT)。
すべてのプロジェクトは言うまでもなく、中規模から大規模のプロジェクトは、プロジェクト ジェネレーター(例として Cmake) によって維持する必要があります。
中規模から大規模のプロジェクトでは、すべてのファイルを同じ物理ディレクトリに保持することは不可能です。これは強く推奨されていません (Linux カーネルを含むいくつかのガイドラインによる)。これらのファイルは、物理的に論理的に編成する必要があります。
物理的なプロジェクト ファイル構造の例は次のとおりです。
~example/environment$project tree .
.
|- code
|- core
|- extern
|- docs
|- tests
|- core_tests
|- extern-tests
|- ...
これは、残念ながら code::blocks では、すべてのプロジェクトの物理フォルダーを検索パスに含める必要があることを意味します。
code::blocks 内のファイルは仮想的にも好きなように整理できますが、物理的な構造が論理的であれば、プロジェクトは直感的に参照できるはずです!
code::blocksでは、仮想パスを含めることはできません。
お役に立てれば
韓国語
ヘウィ
Code::Blocks の私のプロジェクトの 1 つで、ソース フォルダーに別のフォルダーを使用しています。クライアント、共通、およびサーバー。
次に、クライアントのコンパイル ターゲットが client と common にあるソース ファイルを使用し、サーバーのコンパイル ターゲットが server と common にあるソース ファイルを使用するように、さまざまなコンパイル ターゲットを設定します。
それがあなたの求めているものかどうかはわかりませんが、これが私のプロジェクトがどのように見えるかの写真です:
