スタティックライブラリには、リンク工程が存在しないので、
依存関係を設定する必要はありません。
（どんな順でビルドしても問題ありません。）

実行ファイルを生成するプロジェクトを、
全てのスタティックライブラリプロジェクトに依存させればよいです。

最終的には実行ファイルをビルドすることになるのですが、
開発途中では１つのライブラリばかり修正とコンパイルを繰り返すことが
よくあります。そのときにライブラリAが利用しているライブラリBに手を加えたら
ライブラリAをビルドするときに自動的にライブラリBをビルドすると便利なのですが。

ライブラリA が ライブラリB の機能を使っていた場合に、
ライブラリB を変更したからといって、ライブラリA をリビルドする必要はありません。
（それとも、必要ないのは承知の上で、
何か別の目的があって、リビルドさせたいということでしょうか？）

もちろん、ライブラリA がライブラリB のヘッダを include していて、
そのヘッダが修正されれば、（依存関係を指定しなくても）
ライブラリA もリビルドされます。

現在作成しているライブラリはプロジェクトごとにカスタムビルドステップで
変更のあったヘッダーファイルとlibファイルを別の場所にインストールしていて
そのライブラリを利用しているライブラリはインストール先を参照しています。

利用しているライブラリのヘッダーを変更してもインストール先のヘッダーには
変更がないので依存関係を設定していないとまったくビルドされません。
依存関係を設定していると必要なファイルだけをビルドしてからインストールし
さらにそのライブラリを利用しているライブラリのビルドも行います。

また、A.lib が B.lib の機能を使っている場合に、B.lib のソースを変更したら
A.lib をビルドするときに自動的に B.lib をビルドしないと B.lib のコンパイル
エラーの発見が遅れるので、できれば B.lib を自動ビルドしてほしいです。

なるほど。

例えば、適当なダミーEXEプロジェクト C を作り、
C が A と B に依存するように設定し、
いつも C を対象にビルドする、というのはどうでしょう？

dairygoodsさんアドバイスありがとうございます。

EXEプロジェクトを作ることも考えたのですが、*.libだけではなく*.hもライブラリの
ビルドによって生成されるのと同じようなビルド構成なので、ビルド順によって
コンパイル結果が変わってしまいます。
ライブラリ間に依存関係がないとビルド順序は不定になるのでプログラムが誤動作
してしまう危険性があります。

依存関係を設定しても lib.exe に依存ライブラリのパスを渡さない方法があるとよい
のですが。

う～ん、あとは、
Makefileを生成して、バッチファイルで順番に実行するとか。

nmake a.libのMakefile
nmake b.libのMakefile