次の方法で共有

メンテナー ガイド

  • [アーティクル]

このドキュメントでは、ポートレシピを追加または更新するときに適用する必要がある一連のポリシーの一覧を示します。 これは、Debian のポリシー マニュアル、Homebrew のメンテナー ガイドライン、および Homebrew の数式クックブックの役割を果たすことを目的としています。

PR 構造体

ポートごとに個別のプル要求を行う

可能な限り、変更を複数の PR に分割します。 これにより、レビューが大幅に容易になり、1 つの一連の変更に関する問題が他の変更ごとに保持されるのを防ぐことができます。

変更されていないファイルの簡単な変更を回避する

たとえば、問題を修正する理由がないポートファイル内の変数の再フォーマットや名前変更は避けてください。 しかし、PRの主な目的(ライブラリの更新)のためにファイルを変更する必要がある場合は、タイプミスの修正のような明らかに有益な変更が評価されます!

他のリポジトリに対して名前を確認する

一度に多くをチェックするのに適したサービスは、Repology です。 追加するライブラリが別のライブラリと混同される可能性がある場合は、名前を変更して明確にすることを検討してください。 名前が長い場合や、同じ名前の将来の使用と競合する可能性が低い場合に優先します。 ポートが GitHub 上のライブラリを参照している場合は、混乱が発生する可能性がある場合は、名前の前に組織のプレフィックスを付けるのが良い方法です。

GitHub Draft PR の使用

GitHub Draft PR は、まだマージする準備ができていない作業に関する CI または人間のフィードバックを得るための優れた方法です。 ほとんどの新しい PR は下書きとして開き、CI が通過したら通常の PR に変換する必要があります。

GitHub Draft PR の詳細については、「ドラフト pull request の概要」を参照してください。

Portfiles

非推奨のヘルパー関数を回避する

現時点では、次のヘルパーは非推奨となっています。

一部の置換ヘルパー関数は、コンシューマーが特定のバージョンで動作をピン留めし、特定のバージョンでヘルパーの動作をロックできるようにするための "ツール ポート" にあります。 次のように、ツール ポートをポート "dependencies"に追加する必要があります。

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

ポートファイル内の過剰なコメントを避ける

理想的には、ポートファイルは短く、単純で、可能な限り宣言型にする必要があります。 PR を送信する前に、コマンドによって導入された create ボイラー プレートのコメントを削除します。

ポートはパスに依存してはなりません

ポートは、どのポートがインストールされているかを変更する形式で既にインストールされているポートに基づいて動作を変更することはできません。 次に例を示します。

> vcpkg install a
> vcpkg install b
> vcpkg remove a

and

> vcpkg install b

の以前aのインストールによる影響に関係なく、インストールされるbファイルは同じである必要があります。 つまり、ポートは、何らかのアクションを実行する前に、別のポートによってインストールされたツリーに何かが提供されているかどうかを検出しようとしないでください。 このような "パス依存" 動作の具体的で一般的な原因については、以下の「機能を定義する場合、依存関係を明示的に制御する」で説明します。

一意のポート属性ルール

vcpkg システム全体では、ユーザーが同時に使用する必要がある 2 つのポートが同じファイルを提供する可能性はありません。 ポートが別のファイルによって既に提供されているファイルをインストールしようとすると、インストールは失敗します。 たとえば、ポートでヘッダーに非常に一般的な名前を使用する場合は、これらのヘッダーを次ではなく includeサブディレクトリに配置する必要があります。

非公式の名前空間に CMake エクスポートを追加する

vcpkg の中核となる設計上の理想は、顧客に "ロックイン" を作成しないことです。 ビルド システムでは、システムのライブラリと vcpkg のライブラリに応じて違いはありません。 そのため、CMake エクスポートまたはターゲットを既存のライブラリに "わかりやすい名前" で追加することは避け、アップストリームは vcpkg と競合することなく独自の公式の CMake エクスポートを追加できます。

そのためには、アップストリーム ライブラリにないポートがエクスポートするすべての CMake 構成をプレフィックスとして持つ unofficial- 必要があります。 その他のターゲットは名前空間内に存在する unofficial::<port>:: 必要があります。

これは、ユーザーに次の情報が表示されることを意味します。

  • find_package(unofficial-<port> CONFIG) 一意の vcpkg パッケージを取得する方法として
  • unofficial::<port>::<target> そのポートからエクスポートされたターゲットとして。

例 :

  • brotli はパッケージを作成し unofficial-brotli 、ターゲットを生成します unofficial::brotli::brotli。

各ポートは、フォルダー${CURRENT_PACKAGES_DIR}/share/${PORT}に名前が付けられたcopyrightファイルを提供する必要があります。 パッケージのライセンス コンテンツをソース ファイル内で使用できる場合は、このファイルを作成する vcpkg_install_copyright()必要があります。 vcpkg_install_copyright また、必要に応じて複数の著作権ファイルをバンドルします。

vcpkg_install_copyright(FILE_LIST "${SOURCE_PATH}/LICENSE")

このファイルを手動で作成する古い方法は、CMake の組み込みコマンドを file 使用することです。 これは、新しいポートでは推奨 vcpkg_install_copyright されませんが、引き続き許可されます。

file(INSTALL "${SOURCE_PATH}/LICENSE" DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}" RENAME copyright)

アップストリーム ソース ファイル内のライセンス コンテンツがテキスト形式 (PDF ファイルなど) copyright にない場合は、ユーザーがライセンス要件を見つける方法に関する説明を含める必要があります。 可能であれば、これを示す元のソース ファイルへのリンクも含める必要があるため、ユーザーは最新の状態であればチェックできます。

file(WRITE "${CURRENT_PACKAGES_DIR}/share/${PORT}/copyright" [[As of 2023-07-25, according to
https://github.com/GPUOpen-LibrariesAndSDKs/display-library/blob/master/Public-Documents/README.md#end-user-license-agreement
this software is bound by the "SOFTWARE DEVELOPMENT KIT LICENSE AGREEMENT" PDF located at
https://github.com/GPUOpen-LibrariesAndSDKs/display-library/blob/master/Public-Documents/ADL%20SDK%20EULA.pdf
]])

機能

機能を使用して代替手段を実装しない

特徴は追加機能として扱う必要があります。 インストールしてport[featureB]インストールする場合port[featureA]は、port[featureA,featureB]インストールする必要があります。 さらに、2 番目のポートが依存 [featureA] していて、3 番目のポートが依存 [featureB]している場合、2 番目と 3 番目のポートの両方をインストールすると、依存関係が満たされている必要があります。

この状況のライブラリでは、vcpkg で表される使用可能なオプションのいずれかを選択する必要があり、別の設定を必要とするユーザーは、現時点でオーバーレイ ポートを使用する必要があります。

旧バージョンとの互換性を保つために、現在は受け入れられない既存の例:

  • libgit2では libzip、 open62541 TLS または暗号化バックエンドを選択するための機能がすべて含まれています。 curlには異なる暗号化バックエンド オプションがありますが、実行時に選択できます。つまり、上記のテネットがメイン含まれています。
  • darknet には opencv2、 opencv3依存関係に使用する opencv のバージョンを制御する機能があります。

機能はプレビュー機能またはベータ版の機能を利用する場合があります

上記にかかわらず、プレビュー機能がプレビュー以外の機能 (API の削除なしなど) を中断しない可能性が高いプレビュー ブランチなどがある場合は、この設定をモデル化できます。

例 :

  • (フォーム azure-Xxxの) Azure SDK には機能があります public-preview 。
  • imgui には、 experimental-docking それぞれのパブリック番号付きリリースにアタッチされたマージ コミットを使用するプレビュー ドッキング ブランチを利用する機能があります。

既定の機能では、API ではなく動作を有効にする必要があります

コンシューマーがライブラリに直接依存している場合は、必要な機能を簡単に一覧表示できます (library[feature1,feature2])。 ただし、コンシューマー がライブラリを使用していることを認識 していない場合、それらの機能を一覧表示することはできません。 その隠しライブラリが libarchive 、既存のジェネリック インターフェイスに追加の圧縮アルゴリズム (したがって動作) を追加する場合、既定の機能は、最終的なコンシューマーが直接名前を付けない場合でも、合理的に機能的な推移的ライブラリを構築する方法を提供します。

この機能によって追加の API (または実行可能ファイル、またはライブラリ バイナリ) が追加され、既存の API の動作が変更されない場合は、既定で省略する必要があります。 これは、これらの API を使用するすべてのコンシューマーが、直接参照を介してそれを簡単に要求できるためです。

不明な場合は、機能を既定としてマークしないでください。

発行済みインターフェイスの代替機能を制御するために機能を使用しない

ポートのコンシューマーがそのポートのコア機能のみに依存している場合、高い確率で機能をオンにして破損してはなりません。 これは、代替手段がコンシューマーによって直接制御されるのではなく、コンパイラ設定 /std:c++17 / -std=c++17によって制御される場合にさらに重要です。

旧バージョンとの互換性を保つために、現在は受け入れられない既存の例:

  • redis-plus-plus[cxx17] はポリフィルを制御しますが、設定をインストール済みのツリーにベイクしません。
  • ace[wchar] は、すべての API を受け入れるように const wchar_t* 変更します const char*。

インストールされているツリーに置換が組み込まれている場合、機能によってポリフィルがエイリアスに置き換えられる場合があります

上記にかかわらず、ポートは、次の場合に限り、機能を備えたポリフィルを削除できます。

  1. この機能をオンにすると、ポリフィルがポリフィルエンティティのエイリアスに変更されます
  2. ABI の不一致 "あり得ない" ランタイム エラーが発生する可能性が低い、ポリフィルの状態がインストールされているヘッダーに組み込まれている
  3. ポートのコンシューマーは、両方のモードで動作するコードを記述できます。たとえば、ポリフィルされる typedef を使用する場合とそうでない場合

例:

  • abseil[cxx17]置き換えへの変更absl::string_view、またはstd::string_viewパッチによってベイク要件が実装されます。

基になる代替手段を公開することが重要な場合は、ビルド時にメッセージを提供して、プライベート オーバーレイにポートをコピーする方法をユーザーに指示することをお勧めします。

set(USING_DOG 0)
message(STATUS "This version of LibContoso uses the Kittens backend. To use the Dog backend instead, create an overlay port of this with USING_DOG set to 1 and the `kittens` dependency replaced with `dog`.")
message(STATUS "This recipe is at ${CMAKE_CURRENT_LIST_DIR}")
message(STATUS "See the overlay ports documentation at https://github.com/microsoft/vcpkg/blob/master/docs/specifications/ports-overlay.md")

ビルド手法

ベンダーの依存関係を使用しない

ライブラリの埋め込みコピーは使用しないでください。 すべての依存関係を個別に分割してパッケージ化し、更新してメイン含める必要があります。

CMake の使用を優先する

複数のビルドシステムが使用可能な場合は、CMake を使用することをお選び下さいます。 さらに、必要に応じて、ディレクティブを使用してfile(GLOB)代替ビルドシステムを CMake に書き換える方が簡単でメインが可能になります。

例: abseil

静的バイナリまたは共有バイナリを選択する

既定では、適切な設定BUILD_SHARED_LIBSが渡されますが、vcpkg_cmake_configure()その変数を考慮しないライブラリの場合は、次のスイッチをオンにすることができますVCPKG_LIBRARY_LINKAGE。

string(COMPARE EQUAL "${VCPKG_LIBRARY_LINKAGE}" "static" KEYSTONE_BUILD_STATIC)
string(COMPARE EQUAL "${VCPKG_LIBRARY_LINKAGE}" "dynamic" KEYSTONE_BUILD_SHARED)

vcpkg_cmake_configure(
    SOURCE_PATH ${SOURCE_PATH}
    OPTIONS
        -DKEYSTONE_BUILD_STATIC=${KEYSTONE_BUILD_STATIC}
        -DKEYSTONE_BUILD_SHARED=${KEYSTONE_BUILD_SHARED}
)

機能を定義する場合は、依存関係を明示的に制御します

オプションの依存関係をキャプチャする機能を定義する場合は、機能が明示的に有効になっていないときに依存関係が誤って使用されないようにします。

set(CMAKE_DISABLE_FIND_PACKAGE_ZLIB ON)
set(CMAKE_REQUIRE_FIND_PACKAGE_ZLIB OFF)
if ("zlib" IN_LIST FEATURES)
  set(CMAKE_DISABLE_FIND_PACKAGE_ZLIB OFF)
  set(CMAKE_REQUIRE_FIND_PACKAGE_ZLIB ON)
endif()

vcpkg_cmake_configure(
  SOURCE_PATH ${SOURCE_PATH}
  OPTIONS
    -DCMAKE_DISABLE_FIND_PACKAGE_ZLIB=${CMAKE_DISABLE_FIND_PACKAGE_ZLIB}
    -DCMAKE_REQUIRE_FIND_PACKAGE_ZLIB=${CMAKE_REQUIRE_FIND_PACKAGE_ZLIB}
)

次の使用 vcpkg_check_features() スニペットは同等です。

vcpkg_check_features(OUT_FEATURE_OPTIONS FEATURE_OPTIONS
  FEATURES
    "zlib"    CMAKE_REQUIRE_FIND_PACKAGE_ZLIB
  INVERTED_FEATURES
    "zlib"    CMAKE_DISABLE_FIND_PACKAGE_ZLIB
)

vcpkg_cmake_configure(
    SOURCE_PATH ${SOURCE_PATH}
    OPTIONS
      ${FEATURE_OPTIONS}
)

ZLIB スニペットでは大文字と小文字が区別されます。 詳細については、およびCMAKE_REQUIRE_FIND_PACKAGE_<PackageName>ドキュメントをCMAKE_DISABLE_FIND_PACKAGE_<PackageName>参照してください。

次のいずれかの場合、lib は競合すると見なされます。

  • 定義 main
  • malloc の定義
  • 他のライブラリでも宣言されているシンボルを定義する

競合するライブラリは通常、設計上のものであり、欠陥とは見なされません。 一部のビルド システムは lib ディレクトリ内のすべてのものにリンクするため、これらは名前の付いた manual-linkサブディレクトリに移動する必要があります。

マニフェストと CONTROL ファイル

新しいポートを追加する場合は、新しいマニフェスト構文を使用してポートを定義します。既存のポートを変更するときにマニフェストに変更することもできます。 これを簡単に行うには、コマンドを実行して、既存の vcpkg format-manifest CONTROL ファイルをマニフェスト ファイルに変換します。 変更されていない CONTROL ファイルは変換しないでください。

バージョン管理

フィールドの一般的な規則に "version" 従う

新しいポートを作成するときは、パッケージ作成者が使用するバージョン管理規則に従ってください。 ポートを更新する場合は、アップストリームで特に断りがない限り、引き続き同じ規則を使用します。 規則の詳細については、バージョン管理に関するドキュメントを参照してください。

アップストリームがしばらくリリースを公開していない場合は、最新の変更を取得するためにポートのバージョン管理スキーム version-date を変更しないでください。 これらのコミットには、運用環境の準備ができていない変更が含まれる場合があります。 代わりに、アップストリーム リポジトリに新しいリリースを発行するよう依頼してください。

変更されたポートの "port-version" マニフェスト ファイル内のフィールドを更新する

vcpkg は、このフィールドを使用して、特定のポートが古く、ポートの動作が変更されるたびに変更する必要があるかどうかを判断します。

この規則では、アップストリーム バージョンを変更しないポートへの変更にこのフィールドを使用 "port-version" し、アップストリーム バージョンへの更新が行われた場合に戻り値をゼロにリセット "port-version" します。

例:

  • Zlib のパッケージ バージョンは現在 1.2.1、明示的 "port-version" に指定されていない (a "port-version"0と同等) です。
  • 間違った著作権ファイルがデプロイされていることを発見し、ポートファイル内で修正しました。
  • マニフェスト ファイル内のフィールドを "port-version" 次に更新する 1必要があります。

詳細については、 バージョン管理に関するドキュメント を参照してください。

変更されたポートの versions/ バージョン ファイルを更新する

vcpkg は、一連のメタデータ ファイルを使用してバージョン管理機能を強化します。 これらのファイルは、次の場所にあります。

  • ${VCPKG_ROOT}/versions/baseline.json、(このファイルはすべてのポートに共通です)、
  • ${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json (ポートごとに 1 つ)。

たとえば、 zlib 関連するファイルは次のとおりです。

  • ${VCPKG_ROOT}/versions/baseline.json
  • ${VCPKG_ROOT}/versions/z-/zlib.json

ポートを更新するたびに、そのバージョン ファイルも更新される予定です。

これらのファイルを更新するには、次のようなコマンドを x-add-version 実行することをお勧めします。

vcpkg x-add-version zlib

複数のポートを同時に更新する場合は、代わりに次のコマンドを実行できます。

vcpkg x-add-version --all

変更されたすべてのポートのファイルを一度に更新します。

Note

これらのコマンドを実行する前に、変更をポートにコミットしておく必要があります。 その理由は、これらのバージョン ファイルにはポート ディレクトリの Git SHA が必要であるためです。 ただし、コミットされていないローカル変更がある場合は、 x-add-version コマンドによって警告が表示されます。

詳細については、「バージョン管理のリファレンス」および「レジストリの作成」を参照してください。

Patching

vcpkg はパッケージ ソリューションであり、デプロイするコンポーネントの最終的な所有者ではありません。 場合によっては、コンポーネントとプラットフォームの互換性、またはコンポーネントの互換性を向上させるために、パッチを適用する必要があります。

  • 次の修正プログラムを回避する必要があります。
    • アップストリームは、次の場合と一致しません
    • 脆弱性やクラッシュを引き起こす
    • アップストリーム バージョンの更新メイン維持できない
    • は、vcpkg リポジトリ自体とライセンスの絡み合いを引き起こすのに十分な大きさです

アップストリーム関連パッチについてアップストリーム所有者に通知する

アップストリームでパッチが役に立つ可能性がある場合は、アップストリームにパッチの内容を通知する必要があります。 (依存関係の開発など、アップストリームに関係のない vcpkg 固有の動作を適用するパッチでは、通知は必要ありません)。

アップストリームがパッチと一致しない状況を回避するために、そのようなパッチの適用を少なくとも 30 日間待ちます。

変更が正しいという確信が高い場合は、この待機期間をスキップします。 信頼度の高いパッチの例としては、次のようなものがありますが、これらに限定されません。

  • アップストリームのパッチとしての受け入れ (たとえば、プル要求アップストリームからの特定の変更のバックポートがマージされました)。
  • 不足している s を追加します #include。
  • 小規模で明白な製品コードの修正 (初期化されていない変数の初期化など)。
  • テストや例など、ビルドの無関係な vcpkg コンポーネントを無効にします。

修正プログラムの適用よりもオプションを優先する

設定に直接パッチを適用する vcpkg_configure_xyz() 呼び出しでオプションを設定することをお勧めします。

修正プログラムの適用を回避できる一般的なオプション:

  • [MSBUILD] <PropertyGroup> プロジェクト ファイル内の設定は、パラメーターを使用して /p: オーバーライドできます
  • [CMAKE] find_package(XYz) CMake スクリプトでの呼び出しは、次の方法で無効にすることができます。 -DCMAKE_DISABLE_FIND_PACKAGE_XYz=ON
  • [CMAKE]キャッシュ変数 (としてset(VAR "value" CACHE STRING "Documentation")option(VAR "Documentation" "Default Value")宣言または宣言) は、コマンド ラインで次のように-DVAR:STRING=Foo渡すだけでオーバーライドできます。 1 つの注目すべき例外は、パラメーターが FORCE .set() 詳細については、CMake set のドキュメントを参照してください。

値のオーバーライドよりも修正プログラムの適用を優先するVCPKG_<VARIABLE>

プレフィックスが付いた一部の VCPKG_<VARIABLE> 変数には同等 CMAKE_<VARIABLE>の変数があります。 ただし、それらのすべてが内部パッケージ ビルド に渡されるわけではありません (実装: Windows ツールチェーンを参照)。

次の例を考えてみましょう。

set(VCPKG_C_FLAGS "-O2 ${VCPKG_C_FLAGS}")
set(VCPKG_CXX_FLAGS "-O2 ${VCPKG_CXX_FLAGS}")

'の組み込みツールチェーンを使用すると vcpkg、値 VCPKG_<LANG>_FLAGS が適切な CMAKE_LANG_FLAGS 変数に転送されるため、これが機能します。 しかし、'の変数を認識 vcpkgしていないカスタムツールチェーンは、それらを転送しません。

このため、設定 CMAKE_<LANG>_FLAGS時にビルドシステムに直接パッチを適用することをお勧めしています。

パッチを最小限に抑える

ライブラリに変更を加える場合は、最終的な差分を最小限に抑えるように努めます。 つまり、リージョンに影響を与える変更を行うときは、アップストリームのソース コードを再フォーマットしないでください。 また、条件を無効にする場合は、条件のすべての行を削除するよりも、条件を追加または&& 0条件に追加AND FALSEすることをお勧めします。

ポートが古く、ポートを新しいリリースバージョンに更新すると同じ問題が解決する場合は、パッチを追加しないでください。 vcpkg では、古いバージョンにパッチを適用するよりも、ポートの更新を優先します。ただし、バージョンのバンプによって依存ポートの量が大きくなっている場合を除きます。

これにより、vcpkg リポジトリのサイズを減らしながら、将来のコード バージョンにパッチが適用される可能性が向上します。

パッチに機能を実装しない

vcpkg で修正プログラムを適用する目的は、コンパイラ、ライブラリ、プラットフォームとの互換性を有効にすることです。 適切なオープン ソースの手順に従う代わりに新機能を実装する (問題/PR などを送信する) ためのものではありません。

既定ではテスト/ドキュメント/例をビルドしないでください

新しいポートを送信するときに、オプション (BUILD_TESTSまたはWITH_TESTSPOCO_ENABLE_SAMPLES追加のバイナリが無効になっていることを確認) をチェックします。 これにより、平均ユーザーのビルド時間と依存関係が最小限に抑えられます。

必要に応じて、テストのビルドを test 可能にする機能を追加できますが、これは一覧に Default-Features 含めてはなりません。

ライブラリの既存のユーザーが vcpkg に切り替えるようにする

追加しない CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS

ライブラリの作成者が既に使用している場合を除き、この CMake 機能は C++ テンプレートと十分に対話せず、特定のコンパイラ機能を中断するため、使用しないでください。 .def ファイルを提供せず、__declspec() 宣言を使用しないライブラリは、単に Windows の共有ビルドをサポートしていないため、次のように vcpkg_check_linkage(ONLY_STATIC_LIBRARY)マークする必要があります。

アップストリームによって指定された名前の外部にあるバイナリの名前を変更しないでください

つまり、アップストリーム ライブラリの名前がリリースとデバッグで異なる場合 (libx と libxd)、デバッグ ライブラリの名前 libxを . 逆に、アップストリーム ライブラリがリリースとデバッグで同じ名前を持つ場合は、新しい名前を導入しないでください。

重要な注意事項:

  • 多くの場合、静的バリアントと共有バリアントの名前を共通スキームに変更する必要があります。 これにより、コンシューマーは共通名を使用し、ダウンストリーム リンケージを無視できます。 これは、一度に 1 つしか使用できないため、安全です。

ライブラリで CMake 統合ファイル (foo-config.cmake) が生成される場合は、単に出力アーカイブ/LIB を呼び出す file(RENAME) のではなく、CMake ビルド自体に修正プログラムを適用して名前を変更する必要があります。

最後に、Windows 上の DLL ファイルは、生成された LIB を壊すので、ビルド後に名前を変更しないでください。

マニフェスト

マニフェスト ファイルを書式設定する必要があります。 すべてのマニフェスト ファイルを書式設定するには、次のコマンドを使用します。

> vcpkg format-manifest --all

三つ子

現時点では、コミュニティ以外のトリプレットを追加する要求は受け付けていません。 コミュニティから完全なトリプレット状態への昇格は、主にハードウェアがこのようなトリプレットをテストするための予算に基づいており、実際に使用するものが完全にテストされる可能性を最大化するために vcpkg によって送信されたメトリックによって駆動されます。

次の場合は、コミュニティトリプレットを追加します。

  • 人々が実際にそのコミュニティトリプレットを使用することが実証されています。そして
  • 私たちはそのような三重項が壊れていることを知りません。

たとえば、作成者が実際にそのようなものを使用することを示すのではなく、単に "セットを完成させる" ことを試みているため、トリプレット https://github.com/microsoft/vcpkg/pull/29034 を追加しませんでした。結果を再配置可能にするために patchlf ソリューションが作成されるまで linux-dynamic を追加しませんでした。

便利な実装に関する注意事項

ポートファイルはスクリプト モードで実行されます

's と CMakeLists.txt's は共通の構文とコア CMake 言語コンストラクト ("スクリプト コマンド" とも呼ばれます) を共有しますportfile.cmakeが、ポートファイルは "スクリプト モード" で実行されますがCMakeLists.txt、ファイルは "プロジェクト モード" で実行されます。 これら 2 つのモードの最も重要な違いは、"スクリプト モード" には "Toolchain"、"Language"、"Target" という概念が含まれていないということです。 これらのコンストラクト (例: CMAKE_CXX_COMPILERCMAKE_EXECUTABLE_SUFFIXCMAKE_SYSTEM_NAME, ) に依存するスクリプト コマンドを含む動作は正しくありません。

ポートファイルはトリプレットファイルに設定された変数に直接アクセスできますが CMakeLists.txt、変換は行われません(ただし、多くの場合、変換が行われます VCPKG_LIBRARY_LINKAGEBUILD_SHARED_LIBS)。

ポートファイルによって呼び出されるポートファイルとプロジェクト ビルドは、異なるプロセスで実行されます。 概念的：

+----------------------------+       +------------------------------------+
| CMake.exe                  |       | CMake.exe                          |
+----------------------------+       +------------------------------------+
| Triplet file               | ====> | Toolchain file                     |
| (x64-windows.cmake)        |       | (scripts/buildsystems/vcpkg.cmake) |
+----------------------------+       +------------------------------------+
| Portfile                   | ====> | CMakeLists.txt                     |
| (ports/foo/portfile.cmake) |       | (buildtrees/../CMakeLists.txt)     |
+----------------------------+       +------------------------------------+

ポートファイル内のホストを決定するために、標準の CMake 変数は問題ありません (CMAKE_HOST_WIN32)。

ポートファイル内のターゲットを決定するには、vcpkg triplet 変数を使用する必要があります (VCPKG_CMAKE_SYSTEM_NAME)。

可能な設定の完全な列挙については、トリプレットのドキュメントも参照してください。