CMake パッケージガイドライン - 版の履歴

Kgx: /* ヒントとヒントとテクニック‎ */ ビルド中の FetchContent のダウンロードを回避を翻訳して追加

2023-10-29T18:47:59Z

ヒントとヒントとテクニック‎: ビルド中の FetchContent のダウンロードを回避を翻訳して追加

@@ 77行目: / 77行目: @@
 === バイナリから安全でない {{ic|RPATH}} 参照を削除する ===
-作成されたバイナリが {{ic|RPATH}} に安全でない参照を含むことがあります。これはビルドされたパッケージに対して [[Namcap]] を実行することで確認でき、修正されるべきセキュリティ問題であることがわかります。この問題は、{{ic|1=CMAKE_SKIP_INSTALL_RPATH=YES}} を使用することで修正できる可能性が高いです。または {{ic|1=CMAKE_SKIP_RPATH=YES}} CMake のオプションです。両方を使って実験し、問題のソフトウェアで何がうまくいくかを見る必要があります（両方のオプションを使うことは必要ありません。）
+作成されたバイナリが {{ic|RPATH}} に安全でない参照を含むことがあります。これはビルドされたパッケージに対して [[Namcap]] を実行することで確認でき、修正されるべきセキュリティ問題であることがわかります。この問題は、{{ic|1=CMAKE_SKIP_INSTALL_RPATH=YES}} を使用することで修正できる可能性が高いです。または {{ic|1=CMAKE_SKIP_RPATH=YES}} CMake のオプションです。両方を使って実験し、問題のソフトウェアで何がうまくいくかを見る必要があります(両方のオプションを使うことは必要ありません。)
 === 利用可能な全てのCMakeオプションの取得 ===
-ソフトウェアプロジェクトで利用可能なすべての「見える」CMakeオプションを取得するには、ソースツリーで {{ic|cmake -LAH}} を実行します（メインの {{ic|CMakeLists.txt}} ファイルがあるところです）。
+ソフトウェアプロジェクトで利用可能なすべての「見える」CMakeオプションを取得するには、ソースツリーで {{ic|cmake -LAH}} を実行します(メインの {{ic|CMakeLists.txt}} ファイルがあるところです)。
 もし、後で参照するために出力を保存したい場合は、ファイルにリダイレクトすることができます。
  $ cmake -LAH >options.txt 2>&1
 == テンプレート ==

Kgx: /* 自動最適化フラグオーバーライドの修正 */ 翻訳を修正

2023-06-28T05:16:03Z

自動最適化フラグオーバーライドの修正: 翻訳を修正

← 古い版		2023年6月28日 (水) 14:16時点における版
39行目:		39行目:
	デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。		デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。

	しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。		しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です (例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです) CMake 変数)このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし {{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか?なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。

	いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。		いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。

	{{Warning\|		{{Warning\|
	* ビルドタイプが {{ic\|None}} の場合、一部のソフトウェアが壊れる可能性があります。ビルドタイプが {{ic\|None}} の場合、ソフトウェアが壊れたり、機能が失われたりしないかテストしてください。		* ビルドタイプが {{ic\|None}} の場合、一部のソフトウェアが壊れる可能性があります。ビルドタイプが {{ic\|None}} の場合、ソフトウェアが壊れたり、機能が失われたりしてないかテストしてください。
	* ソフトウェアによっては、ビルドタイプが {{ic\|Release}} でないと動作しないものがあります。~~ソフトウェアについては、~~実験とテストが必要です。		* ソフトウェアによっては、ビルドタイプが {{ic\|Release}} でないと動作しないものがあります。実験とテストが必要です。
	}}		}}

Kgx: /* CMake はデフォルトのコンパイラ最適化フラグを自動的にオーバーライドすることができます */ 項目名を修正

2022-03-09T11:12:03Z

CMake はデフォルトのコンパイラ最適化フラグを自動的にオーバーライドすることができます: 項目名を修正

← 古い版		2022年3月9日 (水) 20:12時点における版
21行目:		21行目:
	ビルドファイルを生成するための内部特性により、CMake が好ましくない動作をすることがあります。そのため、CMake ベースのソフトウェアのために [[PKGBUILD]] を書くときにはいくつかのステップに注意する必要があります。		ビルドファイルを生成するための内部特性により、CMake が好ましくない動作をすることがあります。そのため、CMake ベースのソフトウェアのために [[PKGBUILD]] を書くときにはいくつかのステップに注意する必要があります。

	=== CMake はデフォルトのコンパイラ最適化フラグを自動的にオーバーライドすることができます ===		=== CMake はデフォルトのコンパイラ最適化フラグを自動的にオーバーライドすることがあります ===

	CMake を {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} オプション付きで動かしている人をよく見かけます。上流のプロジェクトでは、ビルド手順にこのオプションをうっかり入れてしまうこともありますが、これは望ましくない振る舞いを生み出します。		CMake を {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} オプション付きで動かしている人をよく見かけます。上流のプロジェクトでは、ビルド手順にこのオプションをうっかり入れてしまうこともありますが、これは望ましくない振る舞いを生み出します。

Kgx: /* Prefix and library install directories */ 翻訳

2022-02-23T04:25:32Z

Prefix and library install directories: 翻訳

← 古い版		2022年2月23日 (水) 13:25時点における版
52行目:		52行目:
	ビルドツールの冗長モードを有効にすることで、CMakeで修正内容が正しく使用されているかどうかを確認することができます。例えば、{{ic\|make}} を使っている場合。(CMakeのデフォルトです) に {{ic\|1=VERBOSE=1}} を追加することで実行できます ({{ic\|1=make VERBOSE=1}} のように。) これにより、実行中のコンパイラコマンドを {{ic\|make}} が出力するようになります。これで [[makepkg]] を実行し、コンパイラが {{ic\|1=-D_FORTIFY_SOURCE=2}} と {{ic\|-O2}} フラグを使っているか出力を確認することができます。各コマンドラインで複数の最適化フラグが表示されている場合、その行の最後のフラグがコンパイラによって使用されます（{{ic\|-O2}} が有効になるためには、最後の最適化フラグが必要です。）		ビルドツールの冗長モードを有効にすることで、CMakeで修正内容が正しく使用されているかどうかを確認することができます。例えば、{{ic\|make}} を使っている場合。(CMakeのデフォルトです) に {{ic\|1=VERBOSE=1}} を追加することで実行できます ({{ic\|1=make VERBOSE=1}} のように。) これにより、実行中のコンパイラコマンドを {{ic\|make}} が出力するようになります。これで [[makepkg]] を実行し、コンパイラが {{ic\|1=-D_FORTIFY_SOURCE=2}} と {{ic\|-O2}} フラグを使っているか出力を確認することができます。各コマンドラインで複数の最適化フラグが表示されている場合、その行の最後のフラグがコンパイラによって使用されます（{{ic\|-O2}} が有効になるためには、最後の最適化フラグが必要です。）

	== Prefix ~~and library install directories~~ ==		== Prefix とライブラリのインストール先 ==

	~~The standard~~ Arch Linux {{ic\|/usr}} ~~prefix~~ ~~can be specified by the~~ {{ic\|1=-DCMAKE_INSTALL_PREFIX=/usr}} CMake ~~option. This is usually needed because a lot of software defaults to install files into the~~ {{ic\|/usr/local}} ~~prefix.~~		Arch Linux 標準の {{ic\|/usr}} Prefix は {{ic\|1=-DCMAKE_INSTALL_PREFIX=/usr}} CMake のオプションで指定できます。多くのソフトウェアがデフォルトでファイルを {{ic\|/usr/local}} という Prefix にインストールするため、これは通常必要です。

			一部のアップストリームプロジェクトは、ライブラリを {{ic\|/usr/lib64}} ディレクトリにインストールするように CMake ファイルを設定します。この場合、{{ic\|1=-DCMAKE_INSTALL_LIBDIR=lib}} CMake オプションを使用して、ライブラリのインストールディレクトリを {{ic\|/usr/lib}} に正しく設定できます。
	Some upstream projects set their CMake files to install libraries into the {{ic\|/usr/lib64}} directory. If this is the case, you can correctly set the library installation directory to {{ic\|/usr/lib}} by using the {{ic\|1=-DCMAKE_INSTALL_LIBDIR=lib}} CMake option.

	== ヒントとヒントとテクニック‎ ==		== ヒントとヒントとテクニック‎ ==

Kgx: /* 自動最適化フラグオーバーライドの修正 */ 微修正

2022-02-22T13:31:35Z

自動最適化フラグオーバーライドの修正: 微修正

← 古い版		2022年2月22日 (火) 22:31時点における版
39行目:		39行目:
	デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。		デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。

	しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）。このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述)。それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。		しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。

	いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。		いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。

Kgx: /* 参照 */ 翻訳を修正

2022-02-22T13:28:53Z

参照: 翻訳を修正

← 古い版		2022年2月22日 (火) 22:28時点における版
123行目:		123行目:
	* [https://cmake.org/documentation/ CMake ドキュメント]		* [https://cmake.org/documentation/ CMake ドキュメント]
	* [https://cmake.org/cmake/help/latest/ 最新バージョンのドキュメントリファレンス]		* [https://cmake.org/cmake/help/latest/ 最新バージョンのドキュメントリファレンス]
	* [[Wikipedia:ja:CMake\|CMake Wikipedia 記事]]		* [[Wikipedia:ja:CMake\|CMake Wikipedia]]
	* {{man\|1\|cmake}}		* {{man\|1\|cmake}}

Kgx: /* See also */ 翻訳

2022-02-22T13:28:22Z

Kgx: /* Example packages */ 翻訳

2022-02-22T13:26:33Z

Example packages: 翻訳

← 古い版		2022年2月22日 (火) 22:26時点における版
114行目:		114行目:
	{{Pkg\|cmake}} を [[PKGBUILD#makedepends\|makedepends]] に配置することを忘れないでください。		{{Pkg\|cmake}} を [[PKGBUILD#makedepends\|makedepends]] に配置することを忘れないでください。

	== ~~Example packages~~ ==		== パッケージの例 ==

	* {{Pkg\|i2pd}}		* {{Pkg\|i2pd}}

Kgx: /* Template */ 翻訳

2022-02-22T13:25:57Z

Template: 翻訳

← 古い版		2022年2月22日 (火) 22:25時点における版
87行目:		87行目:
	$ cmake -LAH >options.txt 2>&1		$ cmake -LAH >options.txt 2>&1

	== ~~Template~~ ==		== テンプレート ==

			ここでは、CMake ベースのパッケージの出発点となる {{ic\|build()}} 関数の一般的なテンプレートについて説明します。パッケージの名前は ''foo'' で、C および C++ ベースであり、CMake ファイルの中で {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義していないと仮定します。
	Here is a general template for the {{ic\|build()}} function that serves as a starting point for CMake-based packages. Supposing the package is named ''foo'', it is C and C++ based and that it does not define any required compiler flags for the {{ic\|Release}} build type in the CMake files.

	{{Note\|~~The check function will only work if projects use~~ {{ic\|enable_testing()}} ~~and/or~~ {{ic\|add_test()}} ~~functionality in~~ {{ic\|CMakeFiles.txt}}.}}		{{Note\|このチェック機能は {{ic\|enable_testing()}} と {{ic\|add_test()}} が {{ic\|CMakeFiles.txt}}}} で使われている場合のみ働きます。

	{{hc\|1=PKGBUILD\|2=		{{hc\|1=PKGBUILD\|2=
112行目:		112行目:
	}}		}}

	~~Do not forget to place~~ {{Pkg\|cmake}} in [[makedepends]].		{{Pkg\|cmake}} を [[PKGBUILD#makedepends\|makedepends]] に配置することを忘れないでください。

	== Example packages ==		== Example packages ==

Kgx: /* Tips and tricks */ 翻訳

2022-02-22T13:21:57Z

Tips and tricks: 翻訳

← 古い版		2022年2月22日 (火) 22:21時点における版
58行目:		58行目:
	Some upstream projects set their CMake files to install libraries into the {{ic\|/usr/lib64}} directory. If this is the case, you can correctly set the library installation directory to {{ic\|/usr/lib}} by using the {{ic\|1=-DCMAKE_INSTALL_LIBDIR=lib}} CMake option.		Some upstream projects set their CMake files to install libraries into the {{ic\|/usr/lib64}} directory. If this is the case, you can correctly set the library installation directory to {{ic\|/usr/lib}} by using the {{ic\|1=-DCMAKE_INSTALL_LIBDIR=lib}} CMake option.

			== ヒントとヒントとテクニック‎ ==
	== Tips and tricks ==

	=== ~~Specifying directories~~ ===		=== ディレクトリの指定 ===

			CMake バージョン 3.13 以降、ビルドディレクトリを自動的に作成する {{ic\|-B}} オプションが用意されています。これにより、分離された {{ic\|mkdir}} によるビルドディレクトリの作成が不要になりました。(または {{ic\|install}}) コマンドを使用します。{{ic\|-S}} オプションはソースディレクトリ ({{ic\|CMakeLists.txt}} ファイルを検索する場所) を指定し、 {{ic\|cmake}} を実行する前にソースツリーに {{ic\|cd}} する必要をなくしました。この2つのオプションを組み合わせると、ビルドとソースのディレクトリを指定する便利な方法となります。例えば、''foo'' という名前のプログラムをビルドする場合。
	Since CMake version 3.13, there is a {{ic\|-B}} option that automatically creates the build directory. This avoids the creation of the build directory by a separated {{ic\|mkdir}} (or {{ic\|install}}) command. The {{ic\|-S}} option specifies the source directory (where to search for a {{ic\|CMakeLists.txt}} file) and avoids the need of {{ic\|cd}}'ing into the source tree before executing {{ic\|cmake}}. Combined together, these two options are a convenient way to specify the build and the source directories. For example, for building a program named ''foo'':

	{{hc\|1=PKGBUILD\|2=		{{hc\|1=PKGBUILD\|2=
71行目:		71行目:
	}}		}}

			=== 不要な出力の可能性を低減する===
	=== Reducing possible unneeded output ===

			{{ic\|-Wno-dev}} を使用します。CMake オプションは、{{ic\|CMakeLists.txt}} ファイルを書いた上流プロジェクトの開発者のみを対象とした警告の出力を抑止します。これらの警告を削除することで、CMake の出力がスムーズになり、それを調べる負担が軽減されます。一般的なルールとして、これらの警告は通常パッケージャが安全に無視できるものです。
	The {{ic\|-Wno-dev}} CMake option will suppress the output of some warnings that are meant only for the upstream project developers who write the {{ic\|CMakeLists.txt}} files. Removing these warnings makes the CMake output smoother and reduces the burden on examining it. As a general rule, these warnings usually can be safely ignored by packagers.

	=== ~~Removing insecure~~ {{ic\|RPATH}} ~~references from binaries~~ ===		=== バイナリから安全でない {{ic\|RPATH}} 参照を削除する ===

			作成されたバイナリが {{ic\|RPATH}} に安全でない参照を含むことがあります。これはビルドされたパッケージに対して [[Namcap]] を実行することで確認でき、修正されるべきセキュリティ問題であることがわかります。この問題は、{{ic\|1=CMAKE_SKIP_INSTALL_RPATH=YES}} を使用することで修正できる可能性が高いです。または {{ic\|1=CMAKE_SKIP_RPATH=YES}} CMake のオプションです。両方を使って実験し、問題のソフトウェアで何がうまくいくかを見る必要があります（両方のオプションを使うことは必要ありません。）
	Sometimes the resulting binaries can contain insecure references in {{ic\|RPATH}}. This can be verified by running [[Namcap]] on the built package and consists in a security issue that should be fixed. There is a good chance to fix this by using the {{ic\|1=CMAKE_SKIP_INSTALL_RPATH=YES}} '''or''' {{ic\|1=CMAKE_SKIP_RPATH=YES}} CMake options. You need to experiment with both and see what will work in the software in question (using both options is not needed).

	=== ~~Getting all available~~ CMake ~~options~~ ===		=== 利用可能な全てのCMakeオプションの取得 ===

			ソフトウェアプロジェクトで利用可能なすべての「見える」CMakeオプションを取得するには、ソースツリーで {{ic\|cmake -LAH}} を実行します（メインの {{ic\|CMakeLists.txt}} ファイルがあるところです）。
	For getting all "visible" CMake options that are available for a software project, execute {{ic\|cmake -LAH}} in the source tree (where the main {{ic\|CMakeLists.txt}} file is located).

			もし、後で参照するために出力を保存したい場合は、ファイルにリダイレクトすることができます。
	If you want to save the output for later reference, you can redirect it to a file:

	$ cmake -LAH >options.txt 2>&1		$ cmake -LAH >options.txt 2>&1

← 古い版		2023年6月28日 (水) 14:16時点における版
39行目:		39行目:
	デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。		デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。

	しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。		しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です (例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです) CMake 変数)このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし {{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか?なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。

	いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。		いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。

	{{Warning\|		{{Warning\|
	* ビルドタイプが {{ic\|None}} の場合、一部のソフトウェアが壊れる可能性があります。ビルドタイプが {{ic\|None}} の場合、ソフトウェアが壊れたり、機能が失われたりしないかテストしてください。		* ビルドタイプが {{ic\|None}} の場合、一部のソフトウェアが壊れる可能性があります。ビルドタイプが {{ic\|None}} の場合、ソフトウェアが壊れたり、機能が失われたりしてないかテストしてください。
	* ソフトウェアによっては、ビルドタイプが {{ic\|Release}} でないと動作しないものがあります。~~ソフトウェアについては、~~実験とテストが必要です。		* ソフトウェアによっては、ビルドタイプが {{ic\|Release}} でないと動作しないものがあります。実験とテストが必要です。
	}}		}}

← 古い版		2022年2月22日 (火) 22:31時点における版
39行目:		39行目:
	デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。		デフォルトの {{ic\|None}} ビルドタイプは {{ic\|CFLAGS}} と {{ic\|CXXFLAGS}} にフラグを付加しないので、 {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションも使用可能です。一般的には {{ic\|1=-DCMAKE_BUILD_TYPE=None}} オプションを使う方が {{ic\|CMAKE_BUILD_TYPE}} を省略するよりも良いと言われています。これは {{ic\|CMAKE_BUILD_TYPE}} が省略されたときにアップストリームが自動的にビルドタイプを {{ic\|Release}} に設定する場合をカバーするもので、デフォルトではフラグは付加されず、ビルドタイプ {{ic\|None}} に好ましくないフラグを設定するソフトウェアはまず見当たりません。

	しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）。このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述)。それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。		しかし、残念ながら {{ic\|1=-DCMAKE_BUILD_TYPE=None}} を使えば解決するというような単純なものではありません。{{ic\|-O3}} の問題を解決するために {{ic\|None}} のビルドタイプを使用する場合、別の問題に陥る可能性があります。多くのソフトウェアプロジェクトでは、CMake ファイルで {{ic\|Release}} ビルドタイプに必要なコンパイラフラグを定義するのが一般的です（例えば、{{ic\|CMAKE_C_FLAGS_RELEASE}} と {{ic\|CMAKE_CXX_FLAGS_RELEASE}} を設定するようなものです）。CMake 変数）このようなソフトウェアは、これらの上流で定義されたフラグを使用せずにコンパイルすると、{{ic\|None}} ビルドタイプを使用した場合、壊れたり動作がおかしくなったりする可能性があります。フラグが足りないかどうかを判断するには、CMakeファイルを見る必要がありますし、{{ic\|1=make VERBOSE=1}} の出力を {{ic\|None}} と {{ic\|Release}} ビルドタイプで比較することができます。もし、{{ic\|None}} ビルドタイプで上流で定義されたフラグが見落とされた場合はどうすればいいのでしょうか？なぜなら、{{ic\|Release}} ビルドタイプを使用すると、望ましくない {{ic\|-O3}} フラグを使用する可能性があり、{{ic\|None}} ビルドタイプを使用すると、いくつかの必要な上流定義フラグを見逃す可能性があるからです。この状況を解決する標準的な方法はありませんので、ケースバイケースで分析する必要があります。もし上流が {{ic\|Release}} ビルドタイプに対して {{ic\|-O2}} を定義しているなら、 {{ic\|1=-DCMAKE_BUILD_TYPE=Release}} を使用することができます。(後述) それ以外の場合は、CMake ファイルにパッチを当てることで解決できるかもしれません。

	いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。		いくつかのソフトウェアプロジェクトでは CMake ファイルに {{ic\|-O2}} を {{ic\|Release}} ビルドタイプとしてハードコードしています。

← 古い版		2022年2月22日 (火) 22:28時点における版
119行目:		119行目:
	* {{Pkg\|libmysofa}}		* {{Pkg\|libmysofa}}

	== ~~See also~~ ==		== 参照 ==

	* [https://cmake.org/documentation/ CMake ~~documentation~~]		* [https://cmake.org/documentation/ CMake ドキュメント]
	* [https://cmake.org/cmake/help/latest/ ~~Documentation reference for the latest version~~]		* [https://cmake.org/cmake/help/latest/ 最新バージョンのドキュメントリファレンス]
	* [[Wikipedia:CMake\|Wikipedia ~~article~~]]		* [[Wikipedia:ja:CMake\|CMake Wikipedia 記事]]
	* {{man\|1\|cmake}}		* {{man\|1\|cmake}}