Today, hardly any developer writes the complete source code for an application. Preconfigured libraries for logging, database access, or a geometric modeling kernel speed up solution development. Using libraries lets compilers and linkers access a library's header files and DLLs, whether the libraries are used directly or referenced. Tools such as Maven for Java or NuGet for C# elegantly solve this task. At build time, they fetch the specified libraries from the Internet and resolve their transitive dependencies.

This type of package manager uses two different file types: the package description and the library file. In addition to the library's name and version, the package description contains a list of the other required libraries. Depending on the language used, the libraries themselves are available, say, as Java archives (JAR), C# DLLs, or JavaScript files. Both file types are typically provided on central servers such as Maven Central [1] or NuGet.org [2] and can be downloaded from there.

Your application includes a package description listing the required libraries. The package manager then downloads the requested package descriptions and library files from the central server before compiling. The package manager also takes care of resolving transitive dependencies before the build process starts using the library file, which is now available locally.

Doing Its Own Thing

Until the advent of solutions such as vcpkg [3] and Conan [4], libraries and their dependencies were typically managed manually in the C++ environment. Vcpkg, an open source solution developed at Microsoft, is available on GitHub [5] under the MIT License; the alternative package manager, Conan, developed by JFrog, is also available under the MIT License on GitHub [6]. Both can be used as standalone tools, but they can also be easily integrated into popular build systems such as CMake or MSBuild.

While Conan relies on precompiled libraries, vcpkg builds the libraries from the source code on the developer's machine. The large number of platforms and compilers makes it difficult to keep fully compiled libraries for all combinations available at a central location. Local builds sidestep this difficulty right from the start. Vcpkg also removes the need to provide a server that is available at all times to download the package description and libraries and to secure it against the risk of spyware downloads.

Figure 1 shows vcpkg's process. When launched, the package manager reads the project manifest, determines the project's dependencies, and searches for them in the cache. If a dependency is not available at this point, it reads the dependency's manifest from the registry and downloads the project sources. The package manager then builds the library and saves it in the cache. Once this has been done for all direct and indirect dependencies, the project itself can be built.

Figure 1: Internal steps taken by vcpkg.

There are two options for the cache. Classic mode uses a central storage location for all projects. In manifest mode, there is a separate storage location for each project. To avoid conflicts between different projects' dependencies, it is generally advisable to use manifest mode.

The manifest for a library consists of at least one file named vcpkg.json. Listing 1 shows an example of the fmt library [7]. In addition to the library name, this file primarily contains a list of the dependencies. Both the library's validity and the dependencies can be restricted to specific platforms if required. Where the use case is more complex (e.g., if other repositories need to resolve dependencies), you can enforce additional information in the optional vcpkg-configuration.json file. Listing 2 show an example CMake file.

{
  "name": "fmt",
  "version": "9.1.0",
  "port-version": 1,
  "description": "Formatting library for C++. ... ",
  "homepage": "https://GitHub.com/fmtlib/fmt",
  "license": "MIT",
  "dependencies": [
  {
  "name": "vcpkg-cmake",
  "host": true
  },
  {
  "name": "vcpkg-cmake-config",
  "host": true
  }
  ]
}

cmake_minimum_required(VERSION 3.25)
set(VCPKG_EXAMPLE_VERSION 0.1.0)
project(vcpkg-example VERSION ${VCPKG_EXAMPLE_VERSION} LANGUAGES CXX)
# Dependencies
find_package(fmt CONFIG REQUIRED)
find_package(Boost REQUIRED COMPONENTS program_options)
# Set libs to link against
list(APPEND VCPKG_EXAMPLE_LIBS
  fmt::fmt
  Boost::boost
  Boost::program_options)
# Build
add_executable(${PROJECT_NAME} src/main.cc)
target_link_libraries(${PROJECT_NAME} PRIVATE ${VCPKG_EXAMPLE_LIBS})

Step by Step

Using the package manager for your programs is relatively simple. A complete example can be found on the vcpkg [8] GitHub page. Listing 3 shows the steps for compiling on the command line. The commands from lines 1 and 2 load vcpkg and the sample program off GitHub. To initialize the package manager before using it for the first time, change to its directory and call the bootstrap-vcpkg.sh script (lines 3 and 4).

01 $ git clone https://github.com/skfcz/vcpkgBeispiel.git
02 $ git clone https://github.com/Microsoft/vcpkg.git
03 $ cd vcpkgExample
04 $ sh vcpkg/bootstrap-vcpkg.sh
05 [...]
06 $ cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=vcpkg/scripts/buildsystems/vcpkg.cmake
07 $ cmake --build build/ build/vcpkg-example --option World

Next, call CMake in the example program's folder so that it uses the vcpkg toolchain to load and compile the required libraries. As shown in line 6, you do need to set the appropriate CMake option. The same principle applies if you use an IDE. Figure 2 shows the entry for CLion.

Figure 2: Vcpkg configuration in CLion.

Then you just have to wait for vcpkg to resolve the dependencies requested by the sample program in the registry, download their sources, and compile them. If the dependencies are huge, or complex, this can take some time, depending on your system's compute performance.

As a reward for all of this work, the requested libraries' header files and the compiled binaries are now safely stored in the cache directory. The required libraries are listed in the program's package description. The example shown in Listing 4 is a library for handling command-line options and another library for neat string formatting.

{
  "name": "vcpkg-example",
  "version": "0.1.0",
  "dependencies": [
  {
  "name": "boost-program-options"
  },
  {
  "name": "fmt"
  }
  ]
}

Package Collection

On the vcpkg website [3], a search function in Packages will help you find the correct names for the package description entries. You should be able to find a solution for most tasks given that there are 2,000 libraries. Alternatively, you can search for the libraries by calling vcpkg search at the command line.

After compiling the required libraries, the next step is to compile your program with CMake and link to the newly created libraries (Listing 3, line 7). This does not require any changes to the CMake file (Listing 2) compared to a version for locally installed libraries – provided that the libraries can be found using CMake.