パッケージ管理システムってなかったですよね？
いやいや、そんなもの必要ない、ソース(あるいはヘッダとライブラリ)だけあれば、”パッケージ”なんてものは必要ないということは理解しております。
ただ、なんで数々のC/C++関連プロジェクトで、
ヘッダインクルードパスが指定できない
リンク用ライブラリのパスが指定できない
コンパイルエラーとリンクエラーの区別がついていない
などという初歩の初歩でつまづいている現場が多いか、ごみため的に考えてみました。
ただの経験不足でかたずければおっさん連中のプライドも維持できて良いのかもしれませんが、実際、経験のための適切なパスが用意されていないのが問題のような気もします。
そもそも、ヘッダやライブラリファイルへのパス指定をいちいちしないといけない環境が間違っているのではないかと。
Linuxなどのいわゆるディストリビューションでは、開発用ライブラリのパッケージが配布されており、各種パッケージマネージャでヘッダからライブラリから、ソースまでテケトーなディレクトリにインストールされます。
つまりこういうことです。
あ～PNGのライブラリ使いて～。
よしインスコしよう。
# apt-get install libpng12-dev
トゥットゥル～♪
このとき、ヘッダやライブラリがインストールされるパスを知らなくても、
#include <png/png.h>
と書けて、たいていはリンクも成功します。
CPANもにたようなものですが、C/C++の開発用ライブラリパッケージとの違いは、
CPANモジュールははOSのパッケージマネージャからもインストールできるけど
CPANからもインストールできる
という点です。pythonにはeasy_install、phpにはpear、rubyにはgemという感じで、LL系にはそれぞれメジャーなパッケージマネージャがありますよね。これらがディストリのパッケージとは独立して依存関係など管理してくれるのです。
C/C++でももちろん、libpngのソースtar玉をダウンロードして、
$ configure; make; make install
すれば、メジャーなライブラリはたいていうまくインストールできます。(ビバautoconf!
configureスクリプトは依存関係をチェックしてエラーを吐いてくれますし、—helpでインストールオプションも教えてくれます。
ですが、たぶん、このautoconfがもうちょっとおせっかいになりきれていないところが問題なんだと思ったりもします。
# autoconf対応のソースを書くのも大変ぽい
結局autoconf叩きにしかなりませんでしたが、たまたまNuGetのC++対応の旧い記事を見つけて書きなぐってみたの巻っ。
NuGet for C++ – Visual C++ Team Blog – Site Home – MSDN Blogs
The wait is over. NuGet support for C++ projects is here.
