ターゲットのインストール¶
install(TARGETS targets... ] ] ] )
TARGETS
形式は、プロジェクトからのターゲットをインストールするための規則を指定するものです。 インストールされるターゲット出力アーティファクトにはいくつかの種類があります:
ARCHIVE
この種のターゲット アーティファクトには次のものがあります。
-
Static libraries (macOS では
FRAMEWORK
としてマークされている場合を除く、下記参照); -
DLL import libraries (Cygwin などすべての Windows ベース システムで、
RUNTIME
に行く.dll
ライブラリーと異なり、これらは拡張子が.lib
); -
AIX では
ENABLE_EXPORTS
有効で実行ファイル用に作られるリンカインポートファイルが含まれています。
LIBRARY
この種のターゲット成果物には、
-
DLL を除く共有ライブラリ (これらは
RUNTIME
に移動。下記参照)、 -
macOS では
FRAMEWORK
としてマークされた場合 (下記参照) が含まれます。
RUNTIME
この種類のターゲット成果物は次のとおりです:
-
実行形式 (macOS では
MACOSX_BUNDLE
とマークされている場合を除く、下記のBUNDLE
参照); -
DLL (Cygwin などすべての Windows ベース システム。付属の輸入ライブラリは種類
ARCHIVE
のため、注意)。
OBJECTS
バージョン 3.9 で追加されました。
オブジェクト ライブラリに関連付けられたオブジェクト ファイル。
FRAMEWORK
FRAMEWORK
プロパティが付いたスタティック ライブラリと共有ライブラリは、macOS では FRAMEWORK
ターゲットとして扱われるようになりました。
BUNDLE
MACOSX_BUNDLE
プロパティでマークされた実行可能ファイルは、macOSではBUNDLE
ターゲットとして扱われます。
PUBLIC_HEADER
ライブラリと関連付けられたPUBLIC_HEADER
ファイルは、Apple製以外のプラットフォームではPUBLIC_HEADER
引数で指定された場所にインストールされます。 Apple プラットフォーム上の FRAMEWORK
ライブラリでは、関連するファイルはフレームワーク フォルダ内の適切な場所にインストールされるため、この引数によって定義されたルールは無視されます。 詳細はPUBLIC_HEADER
を参照してください。
PRIVATE_HEADER
PUBLIC_HEADER
と似ていますが、PRIVATE_HEADER
ファイルについてです。 詳細はPRIVATE_HEADER
を参照してください。
RESOURCE
PUBLIC_HEADER
とPRIVATE_HEADER
に似ていますが、RESOURCE
ファイル用です。
これらの引数が与えられると、それに続く引数は、引数で指定されたターゲットまたはファイルタイプにのみ適用されます。 何も指定されない場合、インストール・プロパティはすべてのターゲット・タイプに適用されます。
通常の実行ファイル、静的ライブラリ、および共有ライブラリでは、DESTINATION
引数は必要ありません。 これらのターゲットタイプでは、DESTINATION
が省略された場合、GNUInstallDirs
にある適切な変数からデフォルトのインストール先が選択され、その変数が定義されていない場合はビルトインデフォルトの値が設定される。 同じことが、PUBLIC_HEADER
および PRIVATE_HEADER
ターゲット・プロパティを通じてインストールされたターゲットに関連付けられたパブリックおよびプライベート・ヘッダにも当てはまります。モジュール・ライブラリ、Apple バンドル、およびフレームワークには常に宛先を提供する必要があります。 インターフェイスライブラリおよびオブジェクトライブラリについては、宛先を省略することができますが、これらは異なる方法で処理されます(このセクションの最後にあるこのトピックに関する説明を参照してください)。
次の表は、ターゲット タイプとそれに関連する変数、および宛先が指定されていない場合に適用される組み込みの既定値を示しています。
Target Type |
GNUInstallDirs Variable |
Built-Instructionsデフォルト |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ヘッダーをプロジェクト単位にインストールする一般的な慣習に従いたいプロジェクトは、そのプロジェクトののサブディレクトリを指定する必要があります。
ディストリビューションのファイルシステムレイアウトポリシーに準拠したパッケージを作成するために、プロジェクトが DESTINATION
を指定しなければならない場合、適切な GNUInstallDirs
変数で始まるパスを使用することが推奨されています。 次の例では、静的ライブラリが GNUInstallDirs
によって提供されるデフォルトのインストール先にインストールされますが、ヘッダーは上記の推奨に従ってプロジェクト固有のサブディレクトリにインストールされます:
add_library(mylib STATIC ...)set_target_properties(mylib PROPERTIES PUBLIC_HEADER mylib.h)include(GNUInstallDirs)install(TARGETS mylib PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj)
上記の共通オプションに加えて、それぞれのターゲットでは次の追加引数を受け取ることができます:
NAMELINK_COMPONENT
バージョン 3.X で新たに追加されました。12.
いくつかのプラットフォームでは、バージョン管理された共有ライブラリは次のようなシンボリックリンクを持ちます:
lib<name>.so -> lib<name>.so.1
ここで lib<name>.so.1
はライブラリの名前、lib<name>.so
は “namelink” で、-l<name>
が与えられたときにリンカーがライブラリを見つけることが出来るようにするものです。 NAMELINK_COMPONENT
オプションは COMPONENT
オプションと似ているが、sharedlibrary namelink が生成された場合、そのインストールコンポーネントを変更するものである。 指定されない場合、デフォルトはCOMPONENT
の値である。
次の例を考えてみましょう。
install(TARGETS mylib LIBRARY COMPONENT Libraries NAMELINK_COMPONENT Development PUBLIC_HEADER COMPONENT Development )
このシナリオでは、Development
コンポーネントのみのインストールを選択した場合、ヘッダーとネームリンクはライブラリなしでインストールされるでしょう。 (Libraries
コンポーネントもインストールしない場合、namelink はダングリング シンボリックとなり、ライブラリにリンクするプロジェクトではビルド エラーが発生します)。 Libraries
コンポーネントのみをインストールした場合、ヘッダと namelink を除いたライブラリのみがインストールされます。
このオプションは、通常、起動時と開発時のパッケージを分けているパッケージマネージャで使用されます。 例えば、Debian システムでは、ライブラリはランタイムパッケージに、ヘッダーとネームリンクは開発パッケージに含まれることが期待されています。
バージョン管理された共有ライブラリの作成に関する詳細は、VERSION
および SOVERSION
ターゲットプロパティを参照してください。 バージョン管理された共有ライブラリーがネームリンクを持たないプラットフォームや、ライブラリーがバージョン管理されていない場合、NAMELINK_ONLY
オプションは何もインストールされません。
NAMELINK_ONLY
が指定された場合、NAMELINK_COMPONENT
または COMPONENT
のいずれかを使用して、namelink のインストールコンポーネントを指定できますが、通常は COMPONENT
を優先してください。
NAMELINK_SKIP
NAMELINK_ONLY
と似ていますが逆の効果があり、ライブラリターゲットがインストールされると namelink 以外のライブラリファイルをインストールするようになります。 NAMELINK_ONLY
と NAMELINK_SKIP
のどちらも指定されない場合、両方の部分がインストールされる。 バージョン管理された共有ライブラリがシンボリックリンクを持たないプラットフォームや、バージョン管理されていないライブラリの場合、NAMELINK_SKIP
はライブラリをインストールする。
NAMELINK_SKIP
が指定された場合、NAMELINK_COMPONENT
は何の効果もない。 NAMELINK_SKIP
と NAMELINK_COMPONENT
の併用はお勧めしません。
install(TARGETS) コマンドは、トップレベルで以下のオプションも受け付けます:
EXPORT
This option associates the installed target files with an export called<export-name>
このオプションは、インストールされたターゲットファイルを<export-name>
という名前のファイルに関連付けます。 このオプションは、どのターゲット・オプションよりも前に表示されなければなりません。 エクスポートされたターゲットの名前を変更するには、EXPORT_NAME
target プロパティのドキュメントを参照してください。 相対パスが指定された場合、$<INSTALL_PREFIX>
からの相対パスとして扱われます。
このコマンドの TARGETS
を 1 回呼び出すだけで、1 つ以上のプロパティグループを指定することができます。 ターゲットは、異なる場所に複数回インストールすることができます。 仮想的なターゲットmyExe
、mySharedLib
、myStaticLib
を考えてみましょう。 コード:
install(TARGETS myExe mySharedLib myStaticLib RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib/static)install(TARGETS mySharedLib DESTINATION /some/full/path)
は、myExe
を <prefix>/bin
に、myStaticLib
を <prefix>/lib/static
にインストールすることになる。 非DLLプラットフォームでは、mySharedLib
は<prefix>/lib
と/some/full/path
にインストールされます。 DLL プラットフォームでは、mySharedLib
DLL は <prefix>/bin
および /some/full/path
に、そのインポートライブラリは <prefix>/lib/static
および /some/full/path
にインストールされます。
Interface Libraries がインストール対象に含まれている場合、それらは成果物をインストールせず、関連する EXPORT
に含まれることになります。
EXCLUDE_FROM_ALL
target property を TRUE
に設定してターゲットをインストールすると、未定義の動作になります。
New in the version 3.3: DESTINATION
引数として与えられたインストール先は、$<...>
構文の “generator expression” を使用することができます。
New in version 3.13: install(TARGETS) は他のディレクトリに作成されたターゲットをインストールすることができます。 このようなクロスディレクトリのインストールルールを使用する場合、サブディレクトリからmake install
(または類似) を実行すると、他のディレクトリのターゲットが最新であることを保証しません。 target_link_libraries()
または add_dependencies()
を使用して、サブディレクトリ固有のインストール・ルールが実行される前に、そのようなディレクトリ外のターゲットがビルドされるようにすることができます。