CMakeで「configure --prefix = DIR && make all install」に相当するものは何ですか？

しますcmake . && make all install。これは機能しますが、にインストールされ/usr/localます。

別のプレフィックス（たとえば/usr）にインストールする必要があります。

何がcmakeとmakeにインストールするコマンドライン/usrの代わりには/usr/local？

コマンドラインで任意のCMake変数を渡すか、ccmake / cmake-guiを使用してキャッシュされた変数を編集できます。コマンドラインで、

cmake -DCMAKE_INSTALL_PREFIX：PATH = / usr。&&すべてインストールする

プロジェクトを構成し、すべてのターゲットをビルドして、/ usrプレフィックスにインストールします。タイプ（PATH）は厳密には必要ありませんが、Qtベースのcmake-guiにディレクトリ選択ダイアログを表示させます。

コメントとしてのいくつかのマイナーな追加は、単純な等価を提供するだけでは十分でないことを明らかにしています。ベストプラクティスは、ソースではなく外部ビルドディレクトリを使用することです。また、ジェネレータを抽象化するより一般的なCMake構文を使用します。

mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX：PATH = / usr .. && cmake --build。--target install --config Release

かなり長くなり、直接同等ではなくなりましたが、かなり簡潔な形式でベストプラクティスに近づいています... --configは、マルチ構成ジェネレーター（つまり、MSVC）によってのみ使用され、無視されます他人による。

受け付けられた回答の「：PATH」の部分は省略できます。この構文はより覚えやすいかもしれません：

cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install

... ここでの回答で使用されています。

CMakeとAutotoolsの両方で、必ずしも構成時にインストールパスを設定する必要はありません。次のように、インストール時にDESTDIRを使用できます（ここも参照）。

make DESTDIR=<installhere> install

DESTDIRとPREFIXの微妙な違いを説明するこの質問も参照してください。

これは、段階的なインストールを目的としており、たとえば/etc/alternativesシンボリックリンクを介して、プログラムが実行される場所とは異なる場所にプログラムを格納できるようにするためのものです。

ただし、パッケージが再配置可能で、ハードコーディングされた（プレフィックス）パスが設定ステージで設定されている必要がない場合は、スキップすることができます。だから代わりに：

cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install

あなたは走るでしょう：

cmake . && make DESTDIR=/usr all install

user7498341が指摘するように、これはPREFIXを実際に使用する必要がある場合には適切ではないことに注意してください。

CMakeプロジェクトクロスプラットフォームを構築する方法は次のとおりです。

/project-root> mkdir build
/project-root> cd build
/project-root/build> cmake -G "<generator>" -DCMAKE_INSTALL_PREFIX=stage ..
/project-root/build> cmake --build . --target=install --config=Release

• 最初の2行は、ソース外のビルドディレクトリを作成します
• 3行目は、インストール結果を配置する場所を指定するビルドシステムを生成します（これは常に配置し./project-root/build/stageます。絶対パスでない場合、パスは常に現在のディレクトリからの相対パスと見なされます）。
• 4行目は、.前の行で構成されたビルドシステムで構成されたプロジェクトをビルドします。installビルドが必要な場合、必要な依存ターゲットもすべてビルドするターゲットを実行し、ファイルをCMAKE_INSTALL_PREFIX（この場合はです）にコピーします./project-root/build/stage。VisualStudioのようなマルチ構成ビルドの場合は、オプションの--config <config>フラグ。
• cmake --buildコマンドを使用する際の良い点は、異なるコマンドを必要とせずにすべてのジェネレーター（つまり、メイクファイルとVisual Studio）で機能することです。

その後、インストールしたファイルを使用してパッケージを作成するか、他のプロジェクトに含めます...

ブルース・アダムスの回答について：

あなたの答えは危険な混乱を引き起こします。DESTDIRは、ルートツリーからのインストールを対象としています。DESTDIRを指定しなかった場合、ルートツリーに何がインストールされるかを確認できます。PREFIXは、実際のインストールのベースとなるベースディレクトリです。

たとえば、PREFIX = / usr / localは、パッケージの最終的な宛先が/ usr / localであることを示します。DESTDIR = $ HOMEを使用すると、$ HOMEがルート（/）であるかのようにファイルがインストールされます。たとえば、DESTDIRが/ tmp / destdirだった場合、「make install」が何に影響するかがわかります。その精神において、DESTDIRは構築されたオブジェクトに影響を与えるべきではありません。

それを説明するmakefileセグメント：

install:
    cp program $DESTDIR$PREFIX/bin/program

プログラムは、PREFIXが最終（つまり、実動）ディレクトリーのベース・ディレクトリーであると想定する必要があります。DESTDIR = / somethingにインストールされたプログラムをシンボリックリンクする可能性は、単に機能しないため、プログラムがPREFIXに基づいてファイルにアクセスしないことを意味します。cat（1）は、（最も単純な形式で）どこからでも実行できるプログラムです。以下はそうしない例です：

prog.pseudo.in:
    open("@prefix@/share/prog.db")
    ...

prog:
    sed -e "s/@prefix@/$PREFIX/" prog.pseudo.in > prog.pseudo
    compile prog.pseudo

install:
    cp prog $DESTDIR$PREFIX/bin/prog
    cp prog.db $DESTDIR$PREFIX/share/prog.db

$ PREFIX / bin / prog以外の場所からprogを実行しようとした場合、prog.dbは予期された場所にないため、見つかりません。

最後に、/ etc / alternativesは実際にはこの方法では機能しません。ルートツリーにインストールされているプログラムへのシンボリックリンクがあります（たとえば、vi-> / usr / bin / nvi、vi-> / usr / bin / vimなど）。

CMakemakeを使用する場合、実際のジェネレーターを（たとえばを介して）呼び出すことは悪い習慣と見なされています。次のようにすることを強くお勧めします。

1. 構成フェーズ：

   cmake -Hfoo -B_builds/foo/debug -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=/usr
   

2. ビルドとインストールの段階

   cmake --build _builds/foo/debug --config Debug --target install
   

このアプローチを、以下の場合には、発電機は、簡単に（例えば切り替えることができる-GNinjaために忍者任意の発電機固有のコマンドを覚えていなくても、）。

CMake 3.15から、これを実現する正しい方法は以下を使用することです。

cmake --install <dir> --prefix "/usr"

公式ドキュメント