This is the April 2020 blog post on vcpkg, the cross-platform, open source C/C++ library manager. In this post, we will share some information on the 2020.04 release of vcpkg and discuss the vcpkg product roadmap, which we are publishing and will keep up to date over time. To try out vcpkg for yourself and save yourself some time acquiring your project dependencies, follow the instructions on our GitHub repository.

March Vcpkg Activity

We want to start by thanking our contributors to the vcpkg project on GitHub. The following people contributed PRs that were merged to the master branch in March, not including contributions from the core vcpkg engineering team at Microsoft or our partner team at Beyondsoft:

We now have 826 total unique contributors. Thank you for taking the time to build a better library management tool! We are always looking for more contributions – if you want to help out, check out our Contribution Guidelines.

2020.04 Release

This month, we released the 2020.04 update to vcpkg. The release includes several updates to our documentation, a number of product improvements, the addition of 5 new libraries (which we refer to as ‘ports’), and updates to 69 existing ports.

The following remarkable changes have been made to vcpkg:

• (#9446) vcpkg_from_git: Add support for git over ssh (by @marcrambo)
• (#10271) Android Support: Exporting to Android Archive (AAR) (by @atkawa7)
• (#10395) [vcpkg] Make configure meson sane and work for all targets. (by @Neumann-A)
• (#10398) [vcpkg] New policy: SKIP_ARCHITECTURE_CHECK. (by @Neumann-A)
• (#6275) Add initial iOS support (by @alcroito)
• (#10817) [vcpkg] Add x-set-installed command (by @strega-nil)
• (#10521) [vcpkg] Add initial JSON support (by @strega-nil)

The following 5 new libraries have been added:

1. skyr-url (v1.5.1)
2. boringssl (v2020-04-07)
3. quadtree (v2020-04-13)
4. avisynthplus (v3.5.0)
5. c4core (v2020-04-12)

In total, we now support 1322 libraries in the main vcpkg library catalog. Broken down by build configuration (which we also refer to as ‘triplets’), the counts stand as follows:

For an exhaustive list of all changes, check out our Releases page on GitHub.

Vcpkg Product Roadmap

Going forward, we will publish a roadmap on. While we will continue to support new libraries and improving our port count on Linux and macOS, we will also be adding new capabilities to the product based on your feedback and suggestions The following represents our prioritized backlog of experiences we plan to enable:

1. Vcpkg will allow you to cache library binaries to reduce installation times on other machines. Today, vcpkg downloads source code to your machine and builds it locally. This allows you to produce a binary that is validated against your build requirements and is compatible with your project. But there are instances where the same library, built the same way, is required on multiple machines. Some examples include a continuous integration setup with several build machines, or multiple developers collaborating on the same project from their local dev boxes. Going forward, vcpkg will allow you to do one local build then cache the produced binaries to a file share or binary hosting service of your choice (e.g. Azure Artifact Storage). The next time a “vcpkg install” command is run on another machine, vcpkg will be able to download the pre-build binary directly from the cache instead of running another build. This can save significant time, especially for larger projects with many build machines.
2. Vcpkg will give you more flexibility by letting you specify the versions of libraries to install. By default, vcpkg provides a catalog of over 1300 libraries that are all tested against each other for compatibility at a specific snapshot in time. This means you can pick and choose which dependencies you need without worrying about version conflicts, but it also takes away the flexibility of being able to lock yourself to older versions of specific libraries. We believe a good package manager should be flexible for advanced users, so we will enable a way for users to specify library versions during installs. If you understand your dependency graph and are willing to take on some of the responsibility for compatibility testing, you will be able to stay on older versions as long as you want. We will continue to run our own tests on the catalog, even at some different version levels for different libraries, but due to the extreme combinatoric possibilities here we will not have 100% coverage.
3. Vcpkg will support a manifest file that can specify all your dependencies declaratively and can be checked into source control. The idea is straightforward: you specify your dependencies, versions, and where they can be acquired from (in the case of private dependencies) in a file called vcpkg.json. That file can exist as part of your source code repo, and vcpkg can read the file to immediately acquire everything you need in a consistent way, every time.
4. Vcpkg will allow you to easily install packages from multiple sources. Today, vcpkg is primarily used to download a suite of popular open source libraries. We have over 1300 libraries available, but there are many private 1st party libraries used in enterprise environments and other smaller libraries that are not in our catalog. The goal with this feature is to make it easy to specify a place where libraries exist so you can download them with vcpkg. This way, vcpkg can manage ALL your dependencies, not just your open source ones. While teams will need to spend some time setting up this federated environment for their packages, in the long run it can save everyone time when they set up their development and continuous integration environments.
5. Vcpkg will be shipped with Visual Studio and Visual Studio Code. In Visual Studio, vcpkg will be included in all C++ workloads, while for Visual Studio Code, it will be shipped as part of the C++ extension. Both environments already have some support for vcpkg today, and we will continue improving on that integration going forward. The goal is to have a streamlined experience for acquiring your library dependencies when using these environments, and the first step is having the package manager already there so you can start using it right away.

This roadmap is also published on our GitHub repo wiki, and will be kept up to date there. We will also start publishing technical specifications for these features there; keep an eye out for that in the coming days/weeks.

We welcome your feedback

We look forward to hearing from you about what we are working on. If you would like to reach us, please use the comments below or email visualcpp@microsoft.com. Visit our page on GitHub if you would like to file issues or contribute to the project.