The September 2022 release of the vcpkg package manager is available. This blog post summarizes changes from August 15th, 2022 to September 27th, 2022 for the Microsoft/vcpkg and Microsoft/vcpkg-tool GitHub repos.
vcpkg now has over 2,000 unique libraries in its open-source registry
With this release, and the 6th anniversary of the launch of vcpkg, we are proud to hit a new milestone: over 2,000 unique open-source libraries are available in the vcpkg catalog! vcpkg continues to maintain the largest catalog of any C/C++ package manager with over 10,000 unique library versions with built-in support for many popular architectures, operating systems, and compilers, including x64, x86, arm, arm64, WebAssembly, Linux, macOS, Windows, iOS, Android, FreeBSD, UWP, MSVC, Clang, gcc, mingw, as well as static and shared (dynamic) libraries and more! And of course, since vcpkg is configured to build all these libraries from source, you can make further customizations as needed for your unique workflow.
From the beginning, we have invested extensively in building a large ecosystem of libraries supporting as many development workflows as possible, and we will continue to honor that commitment. While the C++ ecosystem is incredibly diverse, we will rise to the challenge and try to make as many developers as possible more productive. Managing libraries is well understood as a top C++ pain point in annual ISO C++ surveys, but we hope that will change over the next several years.
Some stats for this period:
- 48 new ports were added to the open-source registry. If you are unfamiliar with the term ‘port’, they are packages that are built from source and are typically C/C++ libraries.
- 419 updates were made to existing ports. As always, we validate each change to a port by building all other ports that depend on or are depended by the library that is being updated for our nine main triplets.
- There are now 2,022 total libraries available in the vcpkg public registry. When including all available versions, there are over 10,839 port versions.
- The September release of the main vcpkg repo includes 249 commits.
- 95 contributors submitted PRs, issues, or participated in discussions in the repo.
- The main vcpkg repo has 4.8k forks and 16.8k stars on GitHub.
While last month was relatively quiet, this month’s update includes several vcpkg tool changes. See the full tool commit changelog for details. Notable changes are summarized below.
Optional name and version fields in vcpkg.json
vcpkg.json is the manifest file for specifying library dependencies, versions, optional features and other metadata required for acquiring ports. Previously, two fields were always mandatory for this file:
- name: specifies a name for the project this manifest resides in.
- version: specifies a version for the project this manifest resides in.
These fields are only really useful if your project is a library or other port that you want to package with vcpkg. However, we required the same schema for all projects consuming vcpkg ports (even if they themselves are not a port), which may be confusing for users. From now on, these fields are optional for projects that are only consuming ports, but not producing one. If you’re packaging a library for use in vcpkg however, you absolutely still need to specify these fields as they are critical for consumers to be able to consume your library via vcpkg.
vcpkg artifacts improvements
We are continuing to improve our preview experience for vcpkg artifacts, which enable acquisition of developer tools like compilers and debuggers from vcpkg. These are some changes in this release, especially for multiple registry scenarios:
- The --registryswitch has been removed as registries are required to have a name.
- Commands which take as input registry names or IDs now combine the set of registry names from the global set and the local project.
- Console output now always displays registries using the following rules:
- If the registry URI is in the project, the name of the project is used.
- If the registry URI is not in the project, and the name of the registry in the global configuration does not conflict with the project, the global configuration’s name is used.
- Otherwise, the URI enclosed in s is used. This is a signal to vcpkg users that they will need to provide an appropriate registry name if they want something different.
- The command x-regenerate I now requires a local file path.
- Several places that used to break when handling relative paths now tolerate the situation correctly, including x-regenerate.
- If an artifact declares a dependency from a particular registry, and that registry’s name is not declared in the artifact itself, resolution fails. Vcpkg will no longer try to find the name in the project/global configuration.
- Commands that need activation like add and remove no longer try to activate the project automatically.
- Artifacts are now installed and enumerated in topological sorted order.
- There is no longer a built-in registry named “default”.
- Except for index.yaml, all remaining YAML files have been replaced with JSON. This may invalidate existing installed artifacts. This change was necessary in order to make the artifacts experience more consistent with our existing experience for managing ports.
- Output messages have been cleaned up, including the removal of several newlines.
- Bug fix: the console output no longer gets confused around registry names and no longer displays names using a “[URL]” format when it is unnecessary to do so.
PR: Microsoft/vcpkg-tool#690, Microsoft/vcpkg-tool#693
Cleaned up console output when not connected to a console
We fixed some console output bugs when vcpkg is not connected to a console/TTY. Specifically:
- VT codes when showing tables should now be displayed correctly.
- Progress bars are no longer displayed as the extra output may be undesirable in CI systems and also was not displaying correctly at times.
Added schemata for vcpkg.json, vcpkg-configuration.json, and artifacts
We added official schemas for our manifest files to make it easier to validate that files are authored correctly. In the future, we will also be using this experience to validate manifest files opened in Visual Studio and Visual Studio Code and notify users if errors are present using the IntelliSense experience.
You can try it yourself for the vcpkg.json and vcpkg-configuration.json manifests by
adding the following to the appropriate .json file:
To try it out on JSON files describing artifacts,
add the following to the file:
Total Ports Available for Tested Triplets
While vcpkg supports a much larger variety of target platforms and architectures, the list above is validated exhaustively to ensure updated ports don’t break other ports in the catalog.
Thank you to our contributors
vcpkg couldn’t be where it is today without contributions from our open-source community. Thank you for your continued support! The following people contributed to the vcpkg and vcpkg-tool repos in this release:
- Thomas1664 (21 commits)
- dg0yt (16 commits)
- Neumann-A (14 commits)
- wrobelda (5 commits)
- autoantwort (4 commits)
- m-kuhn (4 commits)
- coryan (4 commits)
- RT222 (2 commits)
- eao197 (2 commits)
- chausner (2 commits)
- Osyotr (2 commits)
- daschuer (1 commit)
- ekilmer (1 commit)
- yurybura (1 commit)
- myd7349 (1 commit)
- an-tao (1 commit)
- past-due (1 commit)
- DragonJoker (1 commit)
- xvitaly (1 commit)
You can find the full September release notes on GitHub for the main repo. Recent updates to the vcpkg tool can be viewed on the vcpkg-tool Releases page. If you’re new to vcpkg or curious about how a package manager can make your life easier as a C/C++ developer, check out the vcpkg website – vcpkg.io.
If you would like to contribute to vcpkg and its library catalog, or want to give us feedback on anything, check out our GitHub repo. Please report bugs or request updates to ports in our issue tracker or join more general discussion in our discussion forum. For an overview of our top priorities and backlog, take a look at our roadmap page.
Interested in vcpkg but not sure where to start?
Is your company experiencing challenges managing C/C++ libraries? Perhaps you’re curious if a package manager is the right choice to you? Please reach out to [email protected] and we’d be happy to help!