結局、プロジェクト構成をどうするのかと言う話になると思うのですが、
特定のアプリケーションにしか使いませんと言うライブラリであれば、
使う側のプロジェクトフォルダに必要なファイルを全てコピーすると言う手も
使えなくないですが、この方法だと使用する側のプロジェクト複数にわたる場合に
ライブラリ側の変更を反映する為に使用するプロジェクト毎に
ファイルをコピーする必要が出てくるので面倒です。

ビルド場所の変更とかライブラリ側の修正を即時反映したいとか考える場合は、
きちんとワークスペース単位でどういう構成にするかを考える必要があります。
例えば、

WorkSpace +
|
+- Static Link Library A Project +
| |
| +- Debug
| |
| +- Release
|
+- Application Project +
|
+- Debug
|
+- Release

こういう風に構成する事を予め決めておいてアプリケーション側は、
追加のインクルードパスを相対アドレス指定でStatic Link LibraryA Projectに
設定します。
更にアプリケーションのDebug時のライブラリパスを相対アドレス指定で
Static Link LibraryA ProjectのDebugに、Release時のライブラリパスを
相対アドレス指定でStatic Link Library A ProjectのReleaseにすれば、
WorkSpaceを何処に持っていってもビルドできる環境が構築できます。

逆にライブラリ側の開発も他の人が並行で行っていて
途中のバージョンは動かない可能性があるような場合は、あえてコピーする方法を
取る場合もありますが、それでもアプリケーション側のプロジェクトフォルダに
コピーするような事は普通しません。

WorkSpace +
|
+- Include
|
+- Lib +
| |
| +- Debug
| |
| +- Release
|
+- Application Project +
|
+- Debug
|
+- Release

このようにリリース版のライブラリとライブラリのインクルードファイルを
置く場所を決めておいて動作確認が取れたものだけを各フォルダにリリース（コピー）
するようにします。
こうした上でライブラリを使用する側（この場合はApplication Project）は、
相対パスで追加インクルードパスとライブラリパスの設定をしておくわけです。
このパス設定をきちんとしておけば、インクルードやライブラリの指定時に
パスを記入する必要はなくなります。コンパイラやリンカがファイルを探して
くれるからです。

ワークスペースとプロジェクトの関係とかプロジェクトファイル上で
プロジェクト外のインクルードファイルやライブラリファイルがどういう扱いに
なっているのかをきちんと把握した上で考えないとうまく行きませんので
実験用にプロジェクトを起こして色々実験してみる事をお勧めします。

ちなみに上記のような構成をしたい場合は空のワークスペースを
予め作成しておいてそれにプロジェクトを追加するようにすると
出来ますのでやってみると良いと思います。

WorkSpace +
|
+- Include
|
+- Lib +
| |
| +- Debug
| |
| +- Release
|
+- Application Project +
|
+- Debug
|
+- Release

この方法は確かにいいですね！！
＞相対パスで追加インクルードパスとライブラリパスの設定をしておくわけです。
この方法も色々試しているうちに理解できるようになりました。

>ちなみに上記のような構成をしたい場合は空のワークスペースを
>予め作成しておいてそれにプロジェクトを追加するようにすると
>出来ますのでやってみると良いと思います。
やってみました。
この方法の場合、ライブラリのヘッダファイルをアプリケーションプロジェクトに追加しなくて
もインクルードするだけで使用できるのですね。

色々、勉強になりました。
ありがとうございます。