Preguntas más frecuentes
Hay dos maneras de administrar las dependencias con vcpkg:
- El modo de manifiesto permite declarar las dependencias directas, las restricciones de versión y los registros usados en un archivo denominado
vcpkg.json. Este archivo debe incluirse en el repositorio de código y se puede comprobar en el sistema de control de código fuente. Las dependencias se instalan en una subcarpeta denominadavcpkg_installed. De este modo, cada proyecto de código puede tener su propio conjunto de dependencias; no se instala nada en todo el sistema. Puede ejecutar vcpkg en modo de manifiesto ejecutandovcpkg install(sin ningún otro argumento) o aprovechando la integración automática con proyectos de MSBuild y CMake. Se recomienda usar manifiestos para los proyectos en el modo clásico en la mayoría de los casos, ya que tiene un mejor control sobre las dependencias. Consulte nuestro artículo Modo de manifiesto para obtener más detalles. - El modo clásico es la forma más tradicional de administrar dependencias, lo que implica ejecutar comandos vcpkg que especifican cada dependencia directa para instalar, modificar o quitar. Las dependencias se almacenan en el directorio de instalación de vcpkg, por lo que varios proyectos que consumen pueden hacer referencia al mismo conjunto de dependencias. Consulte nuestro artículo sobre el modo clásico para obtener más detalles.
Sí. Empiece leyendo nuestras directrices de contribución. Eche un vistazo también a nuestra Guía del mantenedor, en la que se detallan más detalles. También tenemos un tutorial para agregar un puerto a vcpkg para ayudarle a empezar.
Si quiere contribuir pero no tiene una biblioteca determinada en mente, eche un vistazo a la lista de nuevas solicitudes de puerto.
Sí. Consulte el export comando si desea generar archivos binarios para exportarlos a otros entornos.
Como alternativa, si el objetivo es conservar los archivos binarios generados por vcpkg install operaciones para volver a usar más adelante, consulte la característica de almacenamiento en caché binario.
Si usa un manifiesto (vcpkg.json archivo) para administrar las dependencias, debe actualizar ese archivo. Consulte la documentación de referencia de control de versiones para obtener más información.
Si usa vcpkg en modo clásico (ejecutando comandos para administrar paquetes, sin archivo de manifiesto), consulte la documentación del vcpkg update comando. Este comando enumera todos los paquetes que están fuera de sincronización con los archivos de puerto actuales. A continuación, deberá ejecutar el vcpkg upgrade comando para confirmar los cambios.
La lista de bibliotecas se enumera desde el ports\ directorio . Por diseño, puede agregar y quitar bibliotecas de este directorio a medida que vea adecuado para usted o su empresa, consulte nuestros ejemplos sobre el empaquetado de archivos ZIP y repositorios de GitHub.
Se recomienda clonar directamente desde GitHub y usar git pull para actualizar la lista de archivos de puerto.
Sí. Siga nuestro ejemplo de empaquetado para crear su propio puerto y vea la documentación sobre los puertos de superposición y los registros para obtener información sobre cómo administrar los puertos privados.
Puede seguir publicando las bibliotecas privadas en un registro. Consulte el artículo sobre creación de registros. Un registro es una colección de puertos, similar al que se proporciona con vcpkg que contiene código abierto bibliotecas.
Sí. Para portfile.cmake una biblioteca es fundamentalmente un script que coloca los encabezados y archivos binarios en la disposición correcta en ${CURRENT_PACKAGES_DIR}, por lo que para extraer archivos binarios creados previamente, puede escribir un archivo portfile que descargue y organice directamente los archivos.
Para ver un ejemplo de esto, examine ports\opengl\portfile.cmake qué simplemente copia los archivos de Windows SDK.
Nuestros tripletes integrados y probados de integración continua son:
- Escritorio de Windows (x86, x64, x64-static, arm64)
- Plataforma universal de Windows (x64 y arm64)
- Mac OS X (x64-static)
- Linux (x64-static)
- Android (x64, arm64, arm-neon)
Estos destinos se prueban de forma más rigurosa para la compatibilidad con cada versión de vcpkg. Sin embargo, tenemos un número mucho mayor de tripletas de la comunidad disponibles con más plataformas y arquitecturas, incluyendo para iOS, MinGW, WebAssembly, freeBSD y openBSD.
También puede definir sus propios triples en función de sus necesidades. vcpkg es muy personalizable.
Consulte vcpkg help triplet la lista actual y revise nuestra documentación de tripletos para obtener más detalles.
Sí. Probamos continuamente en OS X y Ubuntu 22.04, pero sabemos que los usuarios han tenido éxito con Arch, Fedora y FreeBSD. Si tiene problemas con su distribución favorita de Linux, háganoslo saber en un problema y estaremos encantados de ayudar.
Ejecute git pull para obtener los orígenes más recientes y, a continuación, ejecute bootstrap-vcpkg.bat (Windows) o ./bootstrap-vcpkg.sh (Unix) para actualizar vcpkg. O bien, si usa una copia de vcpkg que se incluye con Visual Studio, basta con actualizar la versión de Visual Studio desde el Instalador de Visual Studio.
Se recomienda usar archivos de manifiesto para administrar dependencias para proyectos individuales, que funcionan incluso si varios proyectos están en la misma máquina y le permiten administrar fácilmente las versiones de paquetes y de las bibliotecas de registros procedentes.
Sin embargo, si usa el modo clásico en su lugar, dentro de una sola instancia de vcpkg (por ejemplo, un conjunto de installed\, packages\, etc ports\ .), solo puede tener instalada una versión de una biblioteca (de lo contrario, los encabezados entrarían en conflicto entre sí). Para aquellos con experiencia con administradores de paquetes de todo el sistema, los paquetes de vcpkg corresponden a los X-dev paquetes o X-devel . En este caso, para usar diferentes versiones de una biblioteca para distintos proyectos, se recomienda crear instancias independientes de vcpkg y usar los mecanismos de integración por proyecto. Las versiones de cada biblioteca se especifican mediante los archivos de ports\, por lo que se manipulan fácilmente mediante comandos estándar git . Esto facilita la reversión de todo el conjunto de bibliotecas a un conjunto coherente de versiones anteriores que funcionan entre sí. Si necesita anclar una biblioteca específica hacia delante, es tan fácil como desprotezclar la versión adecuada de ports\<package>\. Si la aplicación es muy sensible a las versiones de las bibliotecas, se recomienda proteger el conjunto específico de archivos de puerto que necesita en el control de código fuente junto con los orígenes del proyecto y usar la --vcpkg-root opción para redirigir el directorio de trabajo de vcpkg.exe.
Consulte el documento Privacidad para obtener toda la información relacionada con la privacidad.
Sí. Si ya tienes un archivo de cadena de herramientas CMake, necesitarás incluir nuestro archivo de cadena de herramientas al final de tu colección. Esto debe ser tan sencillo como una include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake) directiva. Como alternativa, puede copiar el contenido de nuestro scripts\buildsystems\vcpkg.cmake en el final de su archivo de cadena de herramientas existente.
Sí. En la versión actual, todavía no hay una manera global estandarizada de cambiarlos, pero puede editar archivos de puerto individuales y ajustar el proceso de compilación exacto, pero le gustaría.
Al guardar los cambios en el archivo de puerto (y protegerlos), obtendrá los mismos resultados incluso si está recompilando desde cero en el futuro y olvidó la configuración exacta que usó.
Sí. Aunque vcpkg solo generará las configuraciones estándar "Release" y "Debug" al compilar una biblioteca, puede obtener compatibilidad de integración con las configuraciones personalizadas de los proyectos, además de las configuraciones estándar del proyecto.
En primer lugar, vcpkg asume automáticamente cualquier configuración personalizada a partir de "Release" (resp. "Debug") como una configuración compatible con la configuración estándar "Release" (resp. "Debug") y actuará en consecuencia.
Para otras configuraciones, solo tiene que invalidar la macro de MSBuild $(VcpkgConfiguration) en el archivo de proyecto (.vcxproj) para declarar la compatibilidad entre la configuración y la configuración estándar de destino. Desafortunadamente, debido a la naturaleza secuencial de MSBuild, deberá agregar esa configuración mucho más alta en vcxproj para que se declare antes de que se cargue la integración de vcpkg. Se recomienda agregar la $(VcpkgConfiguration) macro al PropertyGroup "Globals".
Por ejemplo, puede agregar compatibilidad con la configuración "MyRelease" agregando en el archivo de proyecto:
<PropertyGroup Label="Globals">
...
<VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>
Por supuesto, esto solo generará archivos binarios viables si la configuración personalizada es compatible con la configuración de destino (por ejemplo, deben vincularse con la misma biblioteca en tiempo de ejecución).
Sí. Se puede generar un paquete NuGet adecuado para el uso por proyecto mediante el vcpkg integrate project comando (vinculación ligera) o el vcpkg export --nuget comando (shrinkwrapped).
Un mecanismo de nivel inferior para lograr lo mismo que el vcpkg integrate project paquete NuGet es a través del <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets archivo . Lo único que necesita es importarlo en el archivo .vcxproj, reemplazando por <vcpkg_root> la ruta de acceso donde instaló vcpkg:
<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />
Si solo le importan los paquetes instalados, es seguro eliminar los siguientes directorios dentro de la carpeta raíz vcpkg:
packages,buildtrees,- y
downloads
Puede usar la marca en vcpkg install el --clean-after-build comando para que vcpkg elimine los archivos temporales automáticamente una vez completada la compilación.
vcpkg también usa otras ubicaciones temporales externas a la carpeta raíz vcpkg. Los archivos de integración de Visual Studio, la caché binaria predeterminada y la caché de registros; todos se encuentran en la ruta de acceso siguiente en función del sistema operativo:
En Windows:
%LocalAppData%/vcpkg
En Linux/macOS:
$XDG_CACHE_HOME/vcpkg~/.cache/vcpkg(solo siXDG_CACHE_HOMEno está definido)
Si ha configurado cachés binarias o de recursos locales, puede que desee limpiarlas periódicamente según sea necesario.
vcpkg usa CMake internamente como lenguaje de scripting de compilación. Esto se debe a que CMake ya es un sistema de compilación muy común para bibliotecas de código abierto multiplataforma y se está volviendo muy popular para proyectos de C++ en general. Es fácil adquirir en Windows, no requiere instalación en todo el sistema y legible para usuarios desconocidos.
Se recomienda compilar las bibliotecas una vez con las configuraciones de compilación preferidas y usar la característica de almacenamiento en caché binaria para volver a usar archivos binarios sin tener que volver a compilar cada vez. Esto resulta útil al trabajar en un proyecto de equipo o al compilar localmente y en un entorno de integración continua en varias máquinas, contenedores, máquinas virtuales, etc.
Se admite Visual Studio 2015 Update 3 y versiones posteriores.
Habilitar la integración en todo el usuario (vcpkg integrate install) cambia el valor predeterminado para algunas propiedades del proyecto. En concreto, "C/C++/General/Directorios de inclusión adicionales" y "Enlazador/General/Directorios de bibliotecas adicionales" normalmente están en blanco sin integración para todo el usuario. Con la integración, un valor en blanco significa que el valor predeterminado aumentado proporcionado por vcpkg se invalida y no se encontrarán encabezados o bibliotecas. Para restablecer el valor predeterminado, establezca las propiedades que se heredan del elemento primario.
NuGet es un administrador de paquetes para bibliotecas de .NET con una dependencia sólida en MSBuild. No satisface las necesidades específicas de los clientes de C++ nativo de al menos tres maneras.
Tipos de compilación. Con tantas combinaciones posibles de opciones de compilación, la tarea de proporcionar un conjunto de opciones realmente completo es intrínsecamente imposible. Además, el tamaño de descarga para paquetes binarios razonablemente completos se vuelve enorme. Esto hace que sea un requisito dividir los resultados en varios paquetes, pero la búsqueda se vuelve muy difícil.
Binario frente a origen. Muy estrechamente vinculado al primer punto, NuGet está diseñado desde cero para proporcionar archivos binarios relativamente pequeños y creados previamente. Debido a la naturaleza del código nativo, los desarrolladores deben tener acceso al código fuente para garantizar la compatibilidad, el rendimiento, la integridad y la depuración de ABI.
Per-dll frente a Per-application. NuGet está muy centrado en proyectos. Esto funciona bien en lenguajes administrados con ABIs naturalmente estables, ya que las bibliotecas base pueden seguir evolucionando sin interrumpirlas. Sin embargo, en los lenguajes nativos en los que la ABI es mucho más frágil, la única estrategia sólida es compilar explícitamente cada biblioteca con las dependencias exactas que se incluirán en la aplicación final. Esto es difícil de garantizar en NuGet y conduce a un ecosistema altamente desconectado e independiente con versiones.
Conan.io es un administrador de paquetes de C++ federado públicamente, centrado en proyectos, multiplataforma y escrito en Python. Nuestras principales diferencias son:
Federación pública frente a federación privada. Conan se basa en personas que publican copias independientes de cada paquete. Creemos que este enfoque fomenta un gran número de paquetes que están rotos de diferentes maneras. Creemos que es un desperdicio del tiempo del usuario elegir la lista de más de 20 paquetes públicos para Boost 1.56 para determinar el puñado que funcionará para su situación en particular. En cambio, creemos que debe haber una sola versión mantenida de forma colaborativa que funcione para la gran mayoría de los casos y permitir a los usuarios hackear libremente sus versiones privadas. Creemos que esto dará lugar a un conjunto de paquetes de alta calidad que se prueban fuertemente entre sí y forman una base fantástica para cualquier modificación privada que necesite.
Per-dll frente a Per-application. Cuando las dependencias se versionan de forma independiente en un nivel de biblioteca, anima a que cada entorno de compilación sea completamente único, no pueda aprovechar o contribuir a un ecosistema sólido y probado correctamente. En cambio, al versionar todas las bibliotecas juntas como una plataforma (similar a un administrador de paquetes del sistema), esperamos reunir pruebas y esfuerzos en conjuntos muy comunes de versiones de biblioteca para maximizar la calidad y la estabilidad del ecosistema. Esto también diseña completamente la posibilidad de que una biblioteca solicite versiones que entren en conflicto con las opciones de la aplicación (quiero que openssl Z y aumente X, pero X solo notificaciones para trabajar con openssl Y).
Multiplataforma frente a plataforma única. Aunque estar hospedado en muchas plataformas es una estrella norte excelente, creemos que el nivel de integración y estabilidad del sistema proporcionado por apt-get, yum y homebrew es muy conveniente intercambiar
apt-get install libboost-all-devconbrew install boosten scripts automatizados. Decidimos hacer que nuestro sistema sea lo más fácil posible para integrarse en un mundo con estos administradores de sistemas muy exitosos - una línea más paravcpkg install boost- en lugar de intentar reemplazarlos donde ya son tan exitosos y bien amados.C++/CMake frente a Python. Aunque Python es un lenguaje excelente querido por muchos, creemos que la transparencia y la familiaridad son los factores más importantes al elegir una herramienta como importante para el flujo de trabajo como administrador de paquetes. Por lo tanto, decidimos hacer que los lenguajes de implementación sean lo más aceptados universalmente posible: C++ debe usarse en un administrador de paquetes de C++ para programadores de C++. No debe ser necesario aprender otro lenguaje de programación solo para comprender el administrador de paquetes.
Chocolatey es un sistema excelente para administrar aplicaciones. Sin embargo, actualmente no está diseñado para adquirir recursos de desarrollador redistribuibles y ayudarle con la depuración. vcpkg, en comparación, está diseñado para obtener las bibliotecas que necesita para compilar la aplicación y ayudarle a ofrecer a través de cualquier plataforma que quiera (incluido Chocolatey!).
Comentarios de vcpkg
vcpkg es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: