ローカルにインストールしたバイナリ・ライブラリにどうパスを通すか

ある /program/path/ ディレクトリで誰かのプログラムをコンパイル・ビルドした(つまり、直下に bin/lib/include が作成されている)とする。

このパスをグローバルに通すと言うと、おそらく .bash_profile (もしくは .bashrc) に次のように記述するのが一般的ではないだろうか。

export PATH=/program/path/bin:"$PATH"
export LD_LIBRARY_PATH=/program/path/lib:"$LD_LIBRARY_PATH"

あるいは(パスを通すとは少し違うが)、すでにパスが通っているディレクトリにコピーまたはリンクを貼ることもあるだろうか。

$ cp /program/path/bin/* /usr/local/bin/
$ cp /program/path/lib/* /usr/local/lib/

しかし、上のようなやり方では(少なくとも自分にとっては)以下のような不満があった。

  1. export だとインストールしたプログラムが増えると $PATH の中身も肥大化してしまう。また、ディレクトリを移動させた場合に対応できない。
  2. コピーだと実体と切り離されるため、例えば元のソースコードやインストール時のオプションが分からなくなってしまう。リンクだと頑張れば辿れるが、元のディレクトリからはどこにリンクが貼られたか分からないし、export と同じくディレクトリ移動に対応できない。

ところが最近ふと「virtualenv を使えば良いのでは?」と思った。つまり、

$ virtualenv /program/path

でビルドしたディレクトリ自体を1つの virtualenv にしてやって、プログラムを使いたい時は

$ source /program/path/bin/activate

でパスを通す。このやり方のメリットは、

  1. 何をどうやってインストールしたか実体が分かりやすい
  2. ディレクトリを移動しても使える
  3. 環境変数が汚染されない

などがある。しかし当然デメリットもあって、一度に1つの virtualenv にしか入れないため、

  1. ディレクトリ構成が virtualenv と親和性の良いもの(=bin/, lib/, include/ など)でなければならない
  2. 依存関係があるプログラム群は1つのディレクトリにまとめてインストールしなければならない(複数の virtualenv に同時に入ることはできないため)
  3. (2. と関連して) プログラム・ライブラリの再利用性が低い

などがある。1. と 2. はまあ自分でインストール時に調整すれば良いとしても、3. はどうしようもない。

これを解決するには、

汎用性の高い(=依存先が多いと思われる)プログラムやライブラリは従来通り export やコピーで対応して、そうでないほとんど独立したプログラム(群)は virtualenv で1つの環境として切り離す、

もしくは、

妥協して1つの"マスタールートディレクトリ"を作り(例えば ~/software/)、プログラムのディレクトリは全てその下に(~/software/softwareA/)配置して、インストール先は ~/software/bin/ にして、~/software ディレクトリだけを virtualenv 化する、

とかだろうか。後者だともはや従来のコピー手法とほとんど変わらないように思う。。