Hôtes pris en charge

Ce document décrit les architectures et les systèmes d’exploitation pris en charge par vcpkg.

Les dépendances

vcpkg dépend également de quelques composants système à installer avant de pouvoir s’exécuter.

Pour utiliser vcpkg, quelques composants doivent d’abord être installés sur le système.

• Windows : Visual Studio 2017 ou version ultérieure.
• macOS : Outils en ligne de commande Xcode, tar, git, zip, décompresser et curl. La plupart des ports ont également besoin de pkg-config. Nous vous recommandons d’installer ces dépendances via Homebrew, par exemple via une commande brew install zip unzip curl pkgconfigde terminal.
• Linux : compilateur C++ à utiliser, tar, git, zip, décompresser et curl. La plupart des ports ont également besoin de pkg-config. Nous vous recommandons d’installer ces dépendances avec votre gestionnaire de package système.
  • plateformes apt-based : apt install git curl zip unzip pkgconfig
  • plateformes basées sur RPM : dnf install git curl zip unzip pkgconfig
  • plateformes basées sur pacman : base-devel git curl zip unzip tar cmake ninja

Pour les utilisateurs Linux et macOS, nous vous recommandons également d’installer les packages suivants : autoconf, , autoconf-archiveautomakeet makelibtool. Bien qu’ils ne soient pas obligatoires, ces packages sont souvent utilisés par les bibliothèques disponibles dans vcpkg.

Niveaux de prise en charge du registre organisé

La prise en charge est divisée en 4 catégories distinctes. Il s'agit de :

• Entièrement pris en charge et testé
  Configurations utilisées pour tester régulièrement le registre organisé de vcpkg. Les problèmes de ces configurations sont rapidement trouvés et résolus par les maintenances et la communauté de vcpkg..
• Prise en charge complète attendue
  Les configurations traitées avec la même priorité que « Prise en charge complète, testées » mais qui ne font pas partie des tests standard. En général, ces configurations sont sensiblement similaires à l’une des configurations entièrement testées.
• Support de la communauté
  Les configurations qui ne sont pas activement prises en charge par les mainteneurs de vcpkg, mais qui ont un investissement communautaire important. Les maintenances vcpkg acceptent les modifications pour résoudre les problèmes de ces plateformes, mais ne garantissent pas que ces configurations fonctionnent. L’équipe vcpkg souhaite faire passer autant de plateformes que possible du support communautaire vers une prise en charge complète.
• Non pris en charge
  Les configurations connues ne fonctionnent pas pour une raison quelconque. En général, les PR qui corrigent uniquement ces plateformes ne sont pas acceptées.

Prise en charge complète, testée

Les plateformes testées entièrement prises en charge sont les suivantes :

Fenêtres

• Dernière version de Windows/Windows Server. Il s’agit de Windows 11 et Windows Server 2025 à la date de rédaction de ce document.
• La dernière mise à jour de Visual Studio, Visual Studio 2022 version 17.14 à la date de rédaction de ce document.

macOS (arm64 / « Apple Silicon »)

macOS est destiné à suivre la dernière version de macOS et la version contemporaine des outils en ligne de commande Xcode. Toutefois, la mise à jour des machines macOS est un processus manuel et macOS modifie fréquemment les choses de manière à interrompre les tests de vcpkg. À partir de cette écriture, nous utilisons :

• macOS 26.1
• Outils en ligne de commande XCode 26.1

Linux

• La dernière version LTS d’Ubuntu, actuellement 24.04.

Android

• Android NDK pour Linux 64 bits version r29

Prise en charge complète attendue

Fenêtres

• Windows 10 / Windows Server 2019 et versions ultérieures
• Visual Studio 2017 et versions ultérieures

macOS

• La dernière version de macOS, moins 2 versions majeures. Par exemple, la version actuelle de macOS est macOS 26 Tahoe. Nous nous attendons donc à ce que vcpkg fonctionne jusqu’à macOS 14 Sonoma. Cela vise à s’aligner sur la prise en charge de macOS par Apple.
• Versions contemporaines des outils en ligne de commande Xcode pour une version donnée de macOS.
• macOS x64

Linux

Nous avons l’intention de prendre en charge les versions AMD64 des distributions Linux basées sur glibc qui sont toujours prises en charge par leur éditeur et qui ont été publiées au cours des cinq dernières années. Exemples :

• Ubuntu 24.04 et 22.04 sont pris en charge par Canonical et publiés au cours des 5 dernières années. Ils sont donc censés fonctionner. Ubuntu 20.04 est toujours pris en charge par ESM à partir de Canonical mais a été publié il y a plus de 5 ans. Nous ne considérons donc plus qu’il est entièrement pris en charge. 23.10 est plus récent que 22.04, mais nous ne considérons pas qu’il est entièrement pris en charge, car il n’est plus pris en charge par Canonical.
• Red Hat Enterprise Linux 9 est entièrement pris en charge.
• CentOS et Red Hat Enterprise Linux 8 ont quitté le support de Red Hat le 31 mai 2024 et ont été publiés il y a plus de 5 ans, et ne sont donc plus pris en charge.
• CentOS et RHEL 7 ne sont pas pris en charge par Red Hat et ne sont pas censés fonctionner comme ils ont été libérés il y a plus de 5 ans. Le fork Oracle Linux désormais pris en charge par Oracle est toujours pris en charge par Oracle, mais il n’est toujours pas prévu de fonctionner comme il a été publié il y a plus de 5 ans.
• Fedora 43 et 42 sont entièrement pris en charge, mais 41 n’est plus pris en charge par Fedora.
• Debian 13 « Trixie », 12 « Bookworm » et 11 « Bullseye » sont tous pris en charge par Debian et publiés au cours des 5 dernières années. Debian 10 « Buster » a quitté la prise en charge du projet Debian en juillet 2024 et n’est donc pas pris en charge par vcpkg.

Nous partons également du principe que les systèmes de génération des utilisateurs correspondent à la version de Linux qu’ils utilisent, et veillez à ce que les composants tels que l’intégration CMake en mode manifeste fonctionnent avec les versions de ces dépendances qui sont fournies avec l’une des distributions ci-dessus. À ce stade, ces versions de dépendance et les distributions associées sont les suivantes :

• GCC 10.2.1 (Debian 11)
• CMake 3.18.4 (Debian 11)
• Ninja 1.10.0 (Tout)
• Curl 7.74.0 (Debian 11)
• zip 3.0 (Tout)
• unzip 6.0 (Tous)

Assistance de la communauté

Fenêtres

• Windows 7 / Windows Server 2008 R2 et versions ultérieures

vcpkg.exe devrait fonctionner sur les éditions de Windows 7, mais la grande majorité du registre sélectionné nécessite des composants MSYS2 comme pkg-config, qui ne prennent plus en charge les versions de Windows antérieures à 8.1.

• MinGW ou Clang en tant que compilateur de build.

Actuellement, vcpkg repose sur un certain nombre d’hypothèses liées à Visual Studio ; en particulier, nos fonctionnalités qui copient les fichiers PDB correspondants pour les fichiers exécutables nécessitent actuellement dumpbin, un composant de Visual Studio. Nous comptons toutefois plusieurs membres dévoués de la communauté qui attachent de l’importance à la prise en charge de MinGW, et des chaînes d’outils MinGW sont bien incluses d’emblée.

Linux

• Linux non AMD64. Nous sommes extrêmement intéressés par l’aide des personnes ciblant arm64 Linux s’il peut être montré comment fournir des fichiers binaires qui ont une probabilité élevée de succès s’exécutant sur tous les matériels Linux arm64.
• Linux non glibc. Plusieurs outils que vcpkg fournit normalement sont distribués sous forme binaire et supposent que la libc du système est glibc. Nous fournissons bien un binaire de vcpkg basé sur musl libc, que nous avons testé et validé sur Alpine, mais nous ne sommes pas en mesure de fournir des versions basées sur musl libc pour un certain nombre de dépendances telles que CMake.

les systèmes BSD ou d'autres systèmes POSIX

Sur les cibles BSD, aucun binaire vcpkg n’est fourni pour le téléchargement. Au lieu de cela, la logique de démarrage télécharge le code source vcpkg et la compile localement.

OHOS (OpenHarmony / HarmonyOS)

Les triplets arm64-ohosde la communauté, arm-ohoset x64-ohos ciblent la plateforme OHOS, qui est la chaîne d’outils partagée et ABI utilisée par OpenHarmony et l’HarmonyOS de Huawei. Le SDK OpenHarmony ou le SDK HarmonyOS peuvent être utilisés ; tous deux fournissent la chaîne d’outils OHOS (le CMAKE_SYSTEM_NAME=OHOS de CMake, les triples cibles comme aarch64-unknown-linux-ohos). Définissez OHOS_SDK_ROOT de manière à ce qu’il pointe vers le SDK installé.

Les dépendances

vcpkg nécessite un certain nombre de packages logiciels qui ne font pas partie du système d’exploitation et doivent être installés à l’aide du gestionnaire de package :

• FreeBSD : pkg install -y bash cmake curl git ninja zip unzip
• OpenBSD : pkg_add -Iz bash cmake coreutils curl git ninja zip unzip-6.10-iconv

Comme sur Linux, il est recommandé d’installer également des packages supplémentaires :

• FreeBSD : pkg install -y autoconf autoconf-archive gmake pkgconf python
• OpenBSD : pkg_add -Iz autoconf-2.71 autoconf-archive gmake pkgconf python3

Mises en garde

• vcpkg exécute unzip à partir de PATH. À terme, cela peut amener vcpkg à exécuter le unzip fourni par le système d’exploitation, bien qu’une version supplémentaire ait été installée à l’aide du gestionnaire de paquets. La PATH variable d’environnement doit être configurée pour préférer le tiers unzip à celui du système d’exploitation, ou vcpkg ne parvient pas à extraire son cache binaire.

Non pris en charge

• Windows 32 bits. Le ciblage de x86-windows ou d’arm-windows fonctionne très bien, mais vcpkg lui-même s’attend à utiliser des versions AMD64 d’outils de support tels que CMake.
• Visual Studio 2015 ou version antérieure.
• Windows Vista ou version antérieure.
• macOS ou Linux hôtes plus anciens que ceux d’une des autres catégories mentionnées ci-dessus.