ソースファイルを整理するのに問題があります。ソースファイルの構成
私は、私がさまざまなプロジェクトで使用したいと思っている小さなコードだが、成長しているコレクションを持っている。ファイルとフォルダのレイアウトは次のようなものです：
ライブラリ\ SUB1 \ source.h
ライブラリの\ SUB1の\のsource.cpp
ライブラリ\ SUB2 \ source.h
ライブラリ\ SUB2の\のsource.cppの
ワン私の問題は、必要に応じて、私の他のプロジェクトにこのコードを含めることです。これまで、私はlibaryコードを指す絶対パスを使用しましたが、より良い方法が必要です。
さらに、私が使用するすべてのライブラリファイルをプロジェクトのファイルVisual Studioに追加して、正しくコンパイルする必要があります。
私の質問はこれをどのように修正するのですか？上記の状況を処理するための適切な/最良の方法は何ですか。
が適切であるとは思わないが、達成するために何をしようとしているのかによって決まる。
はここが認識しないかもしれないいくつかのものです：あなたは、あなたのプロジェクトに相対パスを使用することができます
。
パスに環境変数を使用できます。
Visual Studioの検索ルールにディレクトリを追加できます。
これはあなたが含まれたファイルを入れて、あなたは、Visual Studioの検索ルールへのフォルダを追加する場合は、すべての任意のパスを含める必要はありませんどこを超えるもう少しコントロールを提供します。
最初に、使用するすべてのディレクトリをプロジェクトのインクルードパスに追加します。可能であれば相対パスとして追加してください。
2番目：使用しているすべてのライブラリ/ソースファイルをプロジェクトに追加する必要があります。これは、プロジェクトエクスプローラまたは[プロジェクト] - [リンカ]タブで実行できます。後者の場合は、使用するディレクトリをプロジェクトライブラリのパスに追加する必要があります。
通常、#includeディレクティブでパスを使用することは好ましくありません。
一般に、ライブラリのソースファイルを他のプロジェクトに直接追加しないでください。それらをライブラリとして別々にコンパイルし、それらを使用します。ライブラリのディレクトリ構造自体を、整理するための
は今、私は次のような構造のようなものに落ち着い
（及び該当する場合）
私は、ライブラリパスに直接すべてのヘッダーを入れ、そしてだけだすべてのものが含まれていますサブフォルダprivateを持っていますライブラリによって使用されますが、共有/公開されるべきではありません。
最大の利点は、
#include "library1/widget.h"
民間がされているだけで
#include "onlyinlib.h"
これは多くの利点があります。新しいライブラリが導入されている場合
サードパーティのコードを含める必要がある場合は、はそれで分岐考えますソース管理に使用するものは何でも：
、この方式では、簡単にサードパーティのライブラリの新しいバージョンにアップグレードしてから、ローカルで行った変更でそれらの変更をマージすることができます。
は例えば、 "LIB1は" 新バージョンをリリースしたとします
これは、ローカル変更を加えたサードパーティライブラリのアップグレードを処理する唯一の唯一の方法です。
なぜ他のプロジェクトにソースコードを組み込みたいのですか？この特別な方法でいくつかのプロジェクトで使用されているソースファイルを使用することは狂気です。あなたは別のプロジェクトを改変する1つのプロジェクトに変更を加える必要があります。また、ライブラリを使用する利点の1つを取り除きます。ソースではなく、libとインクルードファイルのみが必要です。 長期的に、おそらく短期間で時間を節約し、より訓練を受けてください。リポジトリとバージョン管理システム（git、subversionなど）を使用します。あなたが正しく「バージョンアップ」し、テスト済み/提供されたバージョンのライブラリを発行することを確認してください。 – Dipstick
これはコミュニティのwikiに関する質問でしょうか？答えは1つではありませんが、これはソースファイルの編成に関する議論です。 –