自分でビルドしたOpenCVがhomebrewからインストールしたものと違うのはなんで？

Question

前提・実現したいこと

Macです。

C++でOpenCVを使おうと思っています。
homebrewからインストールしたOpenCVは使えるのですが、自分でビルドしたOpenCVではディレクトリの構成が違っていてインクルードできないです。
私は、「Homebrewではすでにビルドしたものが配られている」という認識を持っていたのですが、何か自分が勘違いをしている気がしたので質問をさせていただきました。
答えて頂きたい質問としては、タイトルの通り「自分でビルドしたOpenCVがhomebrewからインストールしたものと違うのはなぜか」ということです。

よろしくお願いします。

補足

ビルドの方法は下に乗せた公式のページの通りに行いました。
Installation in MacOS - OpenCV

Comments

[yumetodo]

それはmake installしたあとですか？

[hoshi-takanori]

勘違いしてたのでコメント削除します。失礼しました。

[RN082491X]

make install はしていませんでした。
make installしたら、usr/local下にOpenCVができました。
ありがとうございます。

公式のビルド手順ではmake installが書かれていなかったのですが、これは何故なのでしょうか。
質問の意図としては、どうすれば自力でこのことに気づけたのか、というようなことを知っておきたいです。
makeについてちゃんとわかってうれば、makeをした後にmake installをするのは常識だったのでしょうか。
よろしくお願いします。

追記
私の認識では、makeをした時点でカレントディレクトリの下にビルドしたものができるものだと思っていました。

[quickquip]

質問はこの欄ではなく質問を編集して書きましょう。

まぁほぼ常識だとは思います。ただ「常識だから書かなくてもいいと思った」のか「書き忘れた」のか、そこの何故を聞かれても答えらる人はいないと思いますが。

[matsuand]

root権限を有しているなら make install をするのがほぼ常識と思います。その点、リンク先のドキュメントでは 「OpenCV_DIR=<path_to_build_or_install_directory>」のように「ビルド先またはインストール先のディレクトリ」と表記されていて、ビルド先だけならまだしも、make install しなければインストール先など登場しないはずなのにそう表現しているため、行間を読まなければならない不親切な説明と思います。make をした時点でカレントディレクトリ内にビルドしたものができるのはそのとおりですが、それはビルドディレクトリ内であり、かつソースディレクトリ内でもあるはずので、通常はそれをずっと残しておくことはしません。この点からも、リンク先ドキュメントはそのディレクトリを残したまま利用させるつもりなのか、不適切なドキュメントに感じます。ついでながら「cmake -DCMAKE_BUILD_TYPE=・省略・ ../opencv」と書いているのも、build_opencv ディレクトリと opencv ディレクトリの相対位置関係が十分に説明されていないので、十分理解していないとビルドできないはずです。不親切なドキュメントであったから仕方ありません。

[jbpb0]

質問者さん
https://docs.opencv.org/master/df/d65/tutorial_table_of_content_introduction.html
を見ると、参考にされてるWebページよりもずっと前に
https://docs.opencv.org/master/d0/d3d/tutorial_general_install.html
があり、それの「Step 3: Build」の次に「Step 3: Install」があります

ただし、「This step is optional」とあるので、参考にされてるWebページでは省略されてるのでしょうね

Answer 1

回答

基本的にCMakeやautotoolsを使ってmakeなどを吐いてビルドするようなものは、makeだけではビルドしただけで、それをmake installするときにライブラリ・実行ファイル・ヘッダーファイル・manファイルなどを適切な位置に配置するようになっています。これは安全のために分けられていると考えることが出来ます。例えば適切な場所への配置にはroot権限が必要になるかもしれません。しかしビルド自体にそんな権限はいらないわけです。ビルド段階の様々なプロセスにまでroot権限を与えるのは必要以上に権限を与えておりあまり安全側に倒した行動とはいえません。

/usr, /usr/local, /mingw32, /mingw64, /opt/foo-x.y.z, ~/などなど、どこに配置するかをmakeを吐く段階(cmakeやconfigure)で与え(cmake -DCMAKE_INSTALL_PREFIX=<path>/./configure --prefix=<path>)、make install(べつにmakeじゃなくてninjaとかでもいいのだけど)した段階でその情報に基づく配置が行われます。

以下余談

このとき事後的にprefixに介入・・・というよりはprefixの場所に展開するという了解のもとにその構造を別の場所に書き出す、環境変数DESTDIRを用いる例もありますが(これとかこれとか)、

コメント欄に言及のあったURLの先にも書かれていて

http://www.linuxfromscratch.org/lfs/view/development/chapter08/pkgmgt.html
(強調はyumetodoによるもの)

If you compile a package that links against libfoo, you may notice that it is linked to /usr/pkg/libfoo/1.1/lib/libfoo.so.1 instead of /usr/lib/libfoo.so.1 as you would expect. The correct approach is to use the DESTDIR strategy to fake installation of the package

コメントでも指摘のある通りパッケージを作るような限定的な条件でのみ使うものと考え忘れて構いません。

Comments

[matsuand]

恐縮ながら誤りがあると思います。まず「OpenCVやautotoolsを使ってmakeなどを」は「CMakeやautotoolsを使ってMakefileなどを」の間違いでは？ また make install が別個に設けられているのは「人によってどこに配置したいかが違うから」と理由づけされていますが、どこに配置するかは configure や cmake の段階で普通定めます。make install があるのは不用意にシステムを破壊しないような誤操作防止のためにあるのだと理解します。

[yumetodo]

ひどいミスだ、直しました。
どこに配置するかは configure や cmake の段階で普通定めるのは確かですが、それが実行されるのはmake installの段階ですよねという意味で書いてました。あるいは本当にmake install時点でいじることもあります(prefixに対する事後的介入
ex. ) https://github.com/msys2/MINGW-packages/blob/508dd4f161b248d0c38f066a471b2e33c9e2997d/mingw-w64-eigen3/PKGBUILD#L56

[matsuand]

おっしゃりたいことはわかります。例は DESTDIR を使ったインストールですね。これは特殊な目的で利用するものであり一般的ではないと解釈します。http://www.linuxfromscratch.org/lfs/view/development/chapter08/pkgmgt.html 8.2.2.3.

[yumetodo]

まあそれもそうなので回答を書き換えてみました。