概念: 機能

  • [アーティクル]

機能

機能は、インストール時にパッケージまたはプロジェクトに選択的に追加できる機能、動作、依存関係のセットを表します。

設計上、機能は次の原則に従う必要があります。

  • 追加: 機能を有効にすると、他の機能を無効にすることなく、パッケージに含まれていない新機能が提供されます。
  • 非排他的: 機能を有効にして、他の機能がインストールされないようにする必要があります。

機能を使用して、代替機能セットを定義しないでください。 たとえば、グラフィックス ライブラリでは、排他的なグラフィックス バックエンドの中から選択する機能を使用しないでください。一度にすべてのグラフィックス バックエンドをインストールすることはできません。

機能は、パッケージの依存関係に次の影響を与える可能性があります。

  • 同じパッケージの他の機能への依存関係など、新しい依存関係を追加します。
  • 既存の依存関係に対して新機能を有効にします。

使用可能な機能のセットは、フィールドによって"features"定義されます。

例 1: 複数のファイル形式

たとえば、イメージ操作ライブラリでは、他のライブラリの異なるセットに応じて、複数の異なるイメージの種類がサポートされる場合があります。

{
  "name": "my-image-lib",
  "version": "0.1",
  "features": {
    "png": { "description": "Support PNG files", "dependencies": ["libpng"]},
    "jpeg": { "description": "Support JPEG files", "dependencies": ["libjpeg-turbo"]},
    "tiff": { "description": "Support TIFF files", "dependencies": ["libtiff"]},
  }
}

既定の機能

既定の機能は、最上位レベルのプロジェクトがビルドを明示的に要求しない場合に自動的にアクティブ化される一連の機能です。 既定の機能は、プロジェクトの依存関係グラフがどのように複雑でカスタマイズ可能かに関係なく、最小限の機能レベルを確保することを目的としています。

Note

既定の機能は、"キュレーション" または "提案" をモデル化するためのものではありません。

たとえば、10 種類以上のアーカイブ形式をサポートするライブラリ "extract-any" について考えてみます。 これらはすべて省略可能であるため、何も選択されていない場合、ライブラリは機能しません。ファイルを抽出することはできません。

既定の機能により、単に依存関係vcpkg.jsonの一覧に追加"extract-any"するユーザーは、ベースライン レベルの機能 (自動選択や.tar.gz展開など) を.zip取得できます。

例 2: 既定の機能の動作

ユーザーが機能をvcpkg.json指定せずに追加"extract-any"すると、既定の機能 (サポートや.tar.gz形式など.zip) が自動的に含まれるため、基本的な機能が保証されます。

{
  "name": "my-application",
  "version": "0.15.2",
  "dependencies": [
    "extract-any"
  ]
}

ユーザーが既定の機能を明示的に無効にする場合は、依存関係に追加 "default-features": false することで、これを行うことができます。

{
  "name": "my-application",
  "version": "0.15.2",
  "dependencies": [
    {
      "name": "extract-any",
      "default-features": false
    }
  ]
}

または、クラシック モードで vcpkg を使用している場合は、この機能を使用して既定の機能をcore無効にすることができます。 たとえば、 vcpkg install extract-any[core] 既定の extract-any 機能を使用せずにインストールすると、 [core] 明示的に除外されます。

詳細については、既定の機能に関する記事をチェック。

依存関係の解決

vcpkg を使用する場合、依存関係の解決は、特に相互依存関係を持つ機能を扱う場合に重要な役割を果たします。 図を示すために、画像操作ライブラリに関連する次のシナリオを考えてみましょう。

{
  "name": "my-image-lib",
  "version": "0.1",
  "features": {
    "png": { "description": "Support PNG files", "dependencies": ["libpng"]},
    "jpeg": { "description": "Support JPEG files", "dependencies": ["libjpeg-turbo"]},
    "tiff": { "description": "Support TIFF files", "dependencies": ["libtiff"]},
  }
}

異なるライブラリが共通ライブラリのさまざまな機能に依存するシナリオでは、vcpkg によって、必要なすべての機能と依存関係が考慮されます。 たとえば、機能が必要でlibrary-b、機能がjpegmy-image-lib必要な場合library-a、依存関係グラフは次pngのようになります。

{
  "name": "library-a",
  "version": "1",
  "dependencies": [{"name": "my-image-lib", "features": ["png"]}]
}

{
  "name": "library-b",
  "version": "1",
  "dependencies": [{"name": "my-image-lib", "features": ["jpeg"]}]
}

{
  "name": "project-using-a-and-b",
  "version": "1",
  "dependencies": [
    "library-a",
    "library-b"
  ]
}

これらの依存関係が解決されると、vcpkg は必要なすべての機能と依存関係を組み合わせて、包括的なインストール 計画を形成します。 この例では、プロジェクトは両方library-aに依存しlibrary-b、両方とJPEGサポートを含むインストール計画になりますが、次の内容はmy-image-lib含PNGまれませんTIFF。

libjpeg-turbo[core]
libpng[core]
library-a[core]
library-b[core]
my-image-lib[core,png,jpeg]

このメカニズムにより、必要な機能に合わせてビルド my-image-lib が最適化され、不要なサポートの PNG サポートが提供され JPEG 、不要 TIFF なサポートは除外されます。

詳細な使用方法

1 つのリポジトリに、いくつかの共有コードを含むクライアント アプリケーションやサーバー アプリケーションなど、複数の個別のビルド可能なコンポーネントが含まれている場合、各部分の開発者は、他の部分に必要な高価な依存関係をインストールしないようにしたい場合があります。

{
  "name": "my-game",
  "dependencies": ["grpc"],
  "features": {
    "client": { "description": "Client Game Executable", "dependencies": ["sdl2", "bullet3"]},
    "server": { "description": "Multiplayer Server Executable", "dependencies": ["proxygen"]},
    "tests": { "description": "Build tests", "dependencies": ["gtest"] }
  }
}

個々の開発者は、インストールする機能を選択できます。

詳細については、「