Lire en anglais

Partager via


Forums Aux Questions (FAQ)

Qu’est-ce que le mode classique et le mode manifeste ?

Il existe deux façons de gérer vos dépendances avec vcpkg :

  1. Le mode manifeste vous permet de déclarer vos dépendances directes, vos contraintes de version et les registres utilisés dans un fichier appelé vcpkg.json. Ce fichier doit être inclus dans votre référentiel de code et peut être archivé dans votre système de contrôle de code source. Les dépendances sont installées dans un sous-dossier nommé vcpkg_installed. Ainsi, chaque projet de code peut avoir son propre ensemble de dépendances ; rien n’est installé à l’échelle du système. Vous pouvez exécuter vcpkg en mode manifeste en exécutant vcpkg install (sans aucun autre argument) ou en tirant parti de l’intégration automatique avec les projets MSBuild et CMake. Nous vous recommandons d’utiliser des manifestes pour vos projets sur le mode classique dans la plupart des cas, car vous avez un meilleur contrôle sur vos dépendances. Pour plus d’informations, consultez notre article en mode manifeste.
  2. Le mode classique est le moyen le plus traditionnel de gérer les dépendances, ce qui implique l’exécution de commandes vcpkg qui spécifient chaque dépendance directe à installer, modifier ou supprimer. Les dépendances sont stockées dans le répertoire d’installation vcpkg, de sorte que plusieurs projets consommants peuvent référencer le même ensemble de dépendances. Pour plus d’informations, consultez notre article en mode Classique.

Puis-je contribuer à une nouvelle bibliothèque ?

Oui ! Commencez par lire notre instructions de contribution. Consultez également notre Guide de maintenance qui fournit plus de détails. Nous avons également un tutoriel pour ajouter un port à vcpkg pour vous aider à commencer.

Si vous souhaitez contribuer, mais n’avez pas de bibliothèque particulière à l’esprit, examinez la liste des nouvelles demandes de port.

Vcpkg peut-il créer des packages binaires prédéfinis ? Quel est le format binaire utilisé par vcpkg ?

Oui ! Consultez la export commande si vous souhaitez produire des fichiers binaires pour l’exportation dans d’autres environnements.

Sinon, si votre objectif est de conserver les fichiers binaires générés par vcpkg install des opérations pour une réutilisation ultérieure, consultez la fonctionnalité de mise en cache binaire

Comment faire les bibliothèques de mises à jour ?

Si vous utilisez un manifeste (fichier vcpkg.json) pour gérer vos dépendances, vous devez mettre à jour ce fichier. Pour plus d’informations, consultez la documentation de référence sur le contrôle de version.

Si vous utilisez vcpkg en mode classique (exécution de commandes pour gérer des packages, aucun fichier manifeste), consultez la vcpkg update documentation de la commande. Cette commande répertorie tous les packages qui ne sont pas synchronisés avec vos fichiers de port actuels. Vous devrez ensuite exécuter la vcpkg upgrade commande pour confirmer les modifications.

Comment faire obtenir plus de bibliothèques ?

La liste des bibliothèques est énumérée à partir du ports\ répertoire. Par conception, vous pouvez ajouter et supprimer des bibliothèques de ce répertoire comme vous le souhaitez pour vous-même ou votre entreprise. Consultez nos exemples sur l’empaquetage de fichiers zipfiles et de dépôts GitHub.

Nous vous recommandons de cloner directement à partir de GitHub et d’utiliser git pull pour mettre à jour la liste des fichiers de port.

Puis-je créer une bibliothèque privée avec cet outil ?

Oui. Suivez notre exemple d’empaquetage pour créer votre propre port et voir la documentation sur les ports et registres de superposition pour apprendre à gérer vos ports privés.

Vous pouvez poursuivre cette opération en publiant vos bibliothèques privées dans un registre. Consultez l’article sur la création de registres. Un registre est une collection de ports, semblable à celui fourni avec vcpkg qui contient des bibliothèques code source ouvert.

Puis-je utiliser une bibliothèque privée prédéfinie avec cet outil ?

Oui. Pour portfile.cmake une bibliothèque, il s’agit essentiellement d’un script qui place les en-têtes et les fichiers binaires dans la disposition correcte dans les ${CURRENT_PACKAGES_DIR}fichiers binaires prédéfinis. Vous pouvez donc écrire un fichier de port qui télécharge et organise directement les fichiers.

Pour voir un exemple de ceci, examinez les fichiers qui copient ports\opengl\portfile.cmake simplement les fichiers à partir du Kit de développement logiciel (SDK) Windows.

Quelles plateformes puis-je cibler avec vcpkg ?

Nos triplets intégrés et testés par intégration continue sont les suivants :

  • Windows Desktop (x86, x64, x64-static, arm64)
  • plateforme Windows universelle (x64 et arm64)
  • Mac OS X (x64 statique)
  • Linux (x64-static)
  • Android (x64, arm64, arm-neon)

Ces cibles sont testées plus rigoureusement pour la compatibilité avec chaque version de vcpkg. Toutefois, nous avons un plus grand nombre de triplets de communauté disponibles avec plus de plateformes et d’architectures, notamment pour iOS, MinGW, WebAssembly, freeBSD et openBSD.

Vous pouvez également définir vos propres triplets en fonction de vos besoins. vcpkg est très personnalisable.

Pour plus d’informations, consultez vcpkg help triplet la liste actuelle et consultez notre documentation sur les triplets.

Vcpkg s’exécute-t-il sur Linux/OS X ?

Oui ! Nous testons continuellement os X et Ubuntu 22.04, mais nous savons que les utilisateurs ont réussi avec Arch, Fedora et FreeBSD. Si vous rencontrez des problèmes avec votre distribution Linux préférée, faites-nous part d’un problème et nous serons heureux d’aider !

Comment faire mettre à jour vcpkg ?

Exécutez git pull pour obtenir les dernières sources, puis exécutez bootstrap-vcpkg.bat (Windows) ou ./bootstrap-vcpkg.sh (Unix) pour mettre à jour vcpkg. Ou, si vous utilisez une copie de vcpkg fournie avec Visual Studio, mettez simplement à jour votre version de Visual Studio à partir de Visual Studio Installer.

Comment faire utiliser différentes versions d’une bibliothèque sur un ordinateur ?

Nous vous suggérons d’utiliser des fichiers manifestes pour gérer les dépendances pour des projets individuels, ce qui fonctionne même si plusieurs projets se trouvent sur le même ordinateur et vous permettent de gérer facilement les versions de package et les bibliothèques de registres qui proviennent.

Toutefois, si vous utilisez plutôt le mode classique, au sein d’une seule instance de vcpkg (par exemple, un ensemble de installed\, ports\ packages\etc.), vous ne pouvez avoir qu’une seule version d’une bibliothèque installée (sinon, les en-têtes seraient en conflit entre eux !). Pour ceux qui ont de l’expérience avec les gestionnaires de packages à l’échelle du système, les packages dans vcpkg correspondent aux X-dev packages ou X-devel aux packages. Dans ce cas, pour utiliser différentes versions d’une bibliothèque pour différents projets, nous vous recommandons de créer des instances distinctes de vcpkg et d’utiliser les mécanismes d’intégration par projet. Les versions de chaque bibliothèque sont spécifiées par les fichiers dans ports\, de sorte qu’elles sont facilement manipulées à l’aide de commandes standard git . Cela facilite la restauration de l’ensemble des bibliothèques dans un ensemble cohérent de versions antérieures qui fonctionnent toutes les unes avec les autres. Si vous devez ensuite épingler une bibliothèque spécifique vers l’avant, c’est aussi simple que d’extraire la version appropriée de ports\<package>\. Si votre application est très sensible aux versions des bibliothèques, nous vous recommandons de vérifier l’ensemble spécifique de fichiers portfiles dont vous avez besoin dans votre contrôle de code source, ainsi que vos sources de projet et d’utiliser l’option --vcpkg-root permettant de rediriger le répertoire de travail de vcpkg.exe.

Comment vcpkg protège-t-il ma confidentialité ?

Consultez le document de confidentialité pour toutes les informations relatives à la confidentialité.

Puis-je utiliser mon propre fichier de chaîne d’outils CMake avec le fichier de chaîne d’outils de vcpkg ?

Oui. Si vous disposez déjà d’un fichier de chaîne d’outils CMake, vous devez inclure notre fichier de chaîne d’outils à la fin de la vôtre. Cela devrait être aussi simple qu’une include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake) directive. Vous pouvez également copier le contenu de notre scripts\buildsystems\vcpkg.cmake fichier de chaîne d’outils existant.

Puis-je utiliser mes propres indicateurs/spécifiques pour reconstruire des bibliothèques ?

Oui. Dans la version actuelle, il n’existe pas encore de méthode globale standardisée pour les modifier, mais vous pouvez modifier des fichiers portfiles individuels et modifier le processus de génération exact, mais vous le souhaitez.

En enregistrant les modifications apportées au fichier portfile (et en les vérifiant), vous obtiendrez les mêmes résultats même si vous regénérerez à partir de zéro à l’avenir et oublié les paramètres exacts que vous avez utilisés.

Puis-je obtenir l’intégration de vcpkg pour les configurations personnalisées ?

Oui. Bien que vcpkg produise uniquement les configurations standard « Release » et « Debug » lors de la création d’une bibliothèque, vous pouvez obtenir la prise en charge de l’intégration pour les configurations personnalisées de vos projets, en plus des configurations standard de votre projet.

Tout d’abord, vcpkg suppose automatiquement toute configuration personnalisée commençant par « Release » (resp. « Déboguer ») comme configuration compatible avec la configuration standard « Release » (resp. « Déboguer ») et agira en conséquence.

Pour les autres configurations, vous devez uniquement remplacer la macro MSBuild $(VcpkgConfiguration) dans votre fichier projet (.vcxproj) pour déclarer la compatibilité entre votre configuration et la configuration standard cible. Malheureusement, en raison de la nature séquentielle de MSBuild, vous devez ajouter ces paramètres beaucoup plus haut dans votre vcxproj afin qu’il soit déclaré avant le chargement de l’intégration vcpkg. Il est recommandé d’ajouter la $(VcpkgConfiguration) macro au Groupe de propriétés « Globals ».

Par exemple, vous pouvez ajouter la prise en charge de votre configuration « MyRelease » en ajoutant dans votre fichier projet :

<PropertyGroup Label="Globals">
  ...
  <VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>

Bien sûr, cela génère uniquement des fichiers binaires viables si votre configuration personnalisée est compatible avec la configuration cible (par exemple, ils doivent tous les deux lier avec la même bibliothèque d’exécution).

Je ne peux pas utiliser l’intégration à l’échelle de l’utilisateur. Puis-je utiliser une intégration par projet ?

Oui. Un package NuGet adapté à l’utilisation par projet peut être généré via la vcpkg integrate project commande (liaison légère) ou la vcpkg export --nuget commande (shrinkwrapped).

Un mécanisme de niveau inférieur pour obtenir la même chose que le vcpkg integrate project package NuGet est via le <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets fichier. Tout ce dont vous avez besoin est de l’importer dans votre fichier .vcxproj, en <vcpkg_root> remplaçant par le chemin d’accès où vous avez installé vcpkg :

<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />

Comment puis-je supprimer des fichiers temporaires ?

Si vous vous souciez uniquement des packages installés, il est sûr de supprimer les répertoires suivants dans le dossier racine vcpkg :

  • packages,
  • buildtrees,
  • et downloads

Vous pouvez utiliser l’indicateur --clean-after-build dans votre vcpkg install commande pour que vcpkg supprime automatiquement les fichiers temporaires une fois la build terminée.

vcpkg utilise également d’autres emplacements temporaires externes au dossier racine vcpkg. Les fichiers d’intégration Visual Studio, le cache binaire par défaut et le cache des registres ; sont tous situés dans le chemin suivant en fonction de votre système opérationnel :

Sur Windows :

  • %LocalAppData%/vcpkg

Sur Linux/macOS :

  • $XDG_CACHE_HOME/vcpkg
  • ~/.cache/vcpkg (uniquement s’il XDG_CACHE_HOME n’est pas défini)

Si vous avez configuré des caches binaires ou de ressources locaux, vous souhaiterez peut-être nettoyer régulièrement ceux-ci en fonction des besoins.

Comment CMake est-il utilisé en interne par vcpkg ?

vcpkg utilise CMake en interne comme langage de script de build. C’est parce que CMake est déjà un système de build extrêmement courant pour les bibliothèques de code source ouvert multiplateformes et devient très populaire pour les projets C++ en général. Il est facile d’acquérir sur Windows, ne nécessite pas d’installation à l’échelle du système et lisible pour les utilisateurs inconnus.

Vcpkg prend-il en charge le téléchargement de fichiers binaires compilés à partir d’un serveur public ou privé ?

Nous vous recommandons de créer vos bibliothèques une fois avec vos configurations de build préférées et d’utiliser la fonctionnalité de mise en cache binaire pour réutiliser les fichiers binaires sans avoir à recréer chaque fois. Cela est utile lorsque vous travaillez sur un projet d’équipe ou lorsque vous créez à la fois localement et dans un environnement d’intégration continue sur plusieurs machines, conteneurs, machines virtuelles, etc.

Quels ensembles d’outils MSVC sont pris en charge ?

Nous prenons en charge Visual Studio 2015 Update 3 et versions ultérieures.

Pourquoi Visual Studio n’utilise-t-il pas mes bibliothèques avec l’intégration à l’échelle de l’utilisateur activée ?

L’activation de l’intégration à l’échelle de l’utilisateur (vcpkg integrate install) modifie la valeur par défaut pour certaines propriétés de projet. En particulier, les répertoires « C/C++/General/Additional Include Directories » et « Linker/General/Additional Library Directories » sont normalement vides sans intégration à l’échelle de l’utilisateur. Avec l’intégration, une valeur vide signifie que la valeur par défaut augmentée fournie par vcpkg est remplacée et que les en-têtes/bibliothèques ne sont pas trouvés. Pour rétablir la valeur par défaut, définissez les propriétés pour hériter du parent.

Pourquoi pas NuGet ?

NuGet est un gestionnaire de package pour les bibliothèques .NET avec une forte dépendance à MSBuild. Il ne répond pas aux besoins spécifiques des clients C++ natifs de trois façons au moins.

  • Saveurs de compilation. Avec autant de combinaisons possibles d’options de compilation, la tâche de fournir un ensemble complet d’options est intrinsèquement impossible. En outre, la taille de téléchargement des packages binaires raisonnablement complets devient énorme. Cela rend nécessaire le fractionnement des résultats en plusieurs packages, mais la recherche devient très difficile.

  • Binaire et source. Très étroitement lié au premier point, NuGet est conçu à partir du terrain pour fournir des binaires relativement petits et prédéfinis. En raison de la nature du code natif, les développeurs doivent avoir accès au code source pour garantir la compatibilité, les performances, l’intégrité et la débogage ABI.

  • Par dll et par application. NuGet est très centré sur le projet. Cela fonctionne bien dans les langages managés avec des API naturellement stables, car les bibliothèques de base peuvent continuer à évoluer sans les briser plus haut. Toutefois, dans les langues natives où l’ABI est beaucoup plus fragile, la seule stratégie robuste consiste à créer explicitement chaque bibliothèque sur les dépendances exactes qui seront incluses dans l’application finale. Cela est difficile à garantir dans NuGet et conduit à un écosystème hautement déconnecté et indépendant.

Pourquoi ne pas Conan ?

Conan.io est un gestionnaire de package C++ centré sur les projets, centré sur les projets, publiquement fédéré et écrit en python. Nos principales différences sont les suivantes :

  • Fédération publique et fédération privée. Conan s’appuie sur des personnes qui publient des copies indépendantes de chaque package. Nous pensons que cette approche encourage un grand nombre de packages qui sont tous rompus de différentes façons. Nous pensons que c’est un gaspillage du temps de l’utilisateur de choisir dans la liste des 20 packages publics pour Boost 1.56 pour déterminer la poignée qui fonctionnera pour leur situation particulière. En revanche, nous pensons qu’il devrait y avoir une version unique et collaborative qui fonctionne pour la grande majorité des cas et permettre aux utilisateurs de pirater librement sur leurs versions privées. Nous pensons que cela entraînera un ensemble de packages de haute qualité qui sont fortement testés les uns avec les autres et forment une base fantastique pour toutes les modifications privées dont vous avez besoin.

  • Par dll et par application. Lorsque les dépendances sont versionnée indépendamment au niveau d’une bibliothèque, il encourage chaque environnement de build à être un environnement de build complètement unique, incapable de tirer parti ou de contribuer à un écosystème solide et bien testé. En revanche, en versionnant toutes les bibliothèques ensemble en tant que plateforme (similaire à un gestionnaire de package système), nous espérons congréguer des tests et des efforts sur des ensembles très courants de versions de bibliothèque pour optimiser la qualité et la stabilité de l’écosystème. Cela conçoit également complètement la possibilité pour une bibliothèque de demander des versions qui entrent en conflit avec les choix de l’application (je veux ouvrir Z et augmenter X, mais X uniquement prétend fonctionner avec openssl Y).

  • Multiplateforme ou plateforme unique. Bien qu’elle soit hébergée sur de nombreuses plateformes est une excellente étoile nord, nous pensons que le niveau d’intégration et de stabilité du système fourni par apt-get, yum et homebrew est très utile pour échanger apt-get install libboost-all-dev avec brew install boost des scripts automatisés. Nous avons choisi de rendre notre système aussi facile que possible d’intégrer dans un monde avec ces gestionnaires de systèmes très réussis - une ligne de plus - vcpkg install boost au lieu de tenter de les remplacer là où ils sont déjà si réussis et bien aimés.

  • C++/CMake vs python. Bien que Python soit un excellent langage aimé par beaucoup, nous pensons que la transparence et la familiarité sont les facteurs les plus importants lors du choix d’un outil aussi important pour votre flux de travail en tant que gestionnaire de package. Par conséquent, nous avons choisi de rendre les langages d’implémentation aussi universellement acceptés que possible : C++ doit être utilisé dans un gestionnaire de package C++ pour les programmeurs C++. Vous ne devez pas être obligé d’apprendre un autre langage de programmation pour comprendre votre gestionnaire de package.

Pourquoi pas Chocolatey ?

Chocolatey est un excellent système de gestion des applications. Toutefois, il n’est pas actuellement conçu pour acquérir des ressources de développeur redistribuables et vous aider à déboguer. vcpkg, en comparaison, est conçu pour vous permettre de créer votre application et de vous aider à fournir toutes les plateformes souhaitées (y compris Chocolatey !).