C++ Package Managers: Escape “Library Install Hell” with vcpkg and Conan

Introduction: installing libraries is too hard

“It took me a day to install Boost”

You tried to add the Boost library to a project, but you had to:

• Download sources
• Run build scripts
• Configure header paths
• Configure library paths
• Deal with different settings per platform

It took a whole day.

Tools like vcpkg and Conan are package managers (they automate downloading, building, and path setup). You only declare dependencies (what you need—name and version), and they download, build, and wire paths for you. The whole team can use the same library versions, which reduces “it works on my PC but fails in CI” issues.

Below is a mermaid example.

// Example flow
flowchart LR
  subgraph manual[Manual install]
    M1[Download sources] --> M2[Build]
    M2 --> M3[Path setup]
    M3 --> M4[Per-platform settings]
  end
  subgraph pm[Package manager]
    P1[vcpkg.json / conanfile] --> P2[Automatic install]
    P2 --> P3[CMake integration]
  end

Fixing it with vcpkg: vcpkg install boost downloads, builds, and installs Boost in one step. After vcpkg integrate install, CMake discovers the vcpkg install path automatically. Then find_package(Boost REQUIRED) sets include and library paths, and target_link_libraries(myapp PRIVATE Boost::boost) links without hand-editing paths. That greatly reduces “a day to install Boost” situations.

Run the following in a terminal.

# After pasting: run from your vcpkg directory. After install, pass -DCMAKE_TOOLCHAIN_FILE=[vcpkg]/scripts/buildsystems/vcpkg.cmake to CMake
vcpkg install boost-asio

# Auto-detected in CMake (when toolchain is set)
# find_package(Boost REQUIRED)
# target_link_libraries(myapp PRIVATE Boost::boost)

Result: vcpkg downloads and builds Boost.Asio; if vcpkg list shows boost-asio, installation succeeded.

Runnable example (minimal C++ you can build after vcpkg is set up):

Example main implementation:

// After pasting: build with CMake using the vcpkg toolchain, or without deps: g++ -std=c++17 -o demo main.cpp && ./demo
#include <iostream>
int main() {
    std::cout << "After aligning the environment with vcpkg, build this project.\n";
    return 0;
}

After reading this post you will be able to:

• Install libraries easily with vcpkg
• Manage dependencies with Conan
• Declare project dependencies explicitly
• Build reproducibly in real projects

---

Practical experience: this article is based on problems and fixes from large C++ projects. It includes production pitfalls and debugging tips that books often skip.

Problem scenarios: package-management pain in practice

Scenario 1: “It builds locally but fails in CI”

Symptom: Local builds succeed, but GitHub Actions or Jenkins reports find_package(fmt) failed.

Cause: Libraries you installed by hand locally are missing in CI. System packages (apt, brew) vary by platform and version.

Fix: Declare dependencies in vcpkg.json or a Conan file, and build in CI with the same toolchain/profile.

Scenario 2: “A library version changed and the build broke”

Symptom: Yesterday’s project fails today after conan install.

Cause: No version range was pinned, so the latest version was pulled; API changes broke compatibility.

Fix: Pin with vcpkg builtin-baseline, or pin explicit versions in Conan (e.g. fmt/9.1.0).

Scenario 3: “Headers resolve but I get link errors”

Symptom: Errors like undefined reference to 'fmt::v9::format(...)'.

Cause: find_package succeeded but target_link_libraries is missing a target, or you mixed static/dynamic (e.g. Release-built fmt linked into Debug).

Fix: Use target_link_libraries(myapp PRIVATE fmt::fmt) explicitly; align build type in triplet/profile.

Scenario 4: “The dependency graph is a mess”

Symptom: Component A needs Boost 1.70 and B needs 1.80, and you must link both.

Cause: Global installs or mixing multiple package managers.

Fix: Isolate per project with manifest mode (vcpkg.json) or a Conan file; use one version per project.

Scenario 5: “Install takes forever”

Symptom: vcpkg install or conan install runs 30+ minutes.

Cause: Building from source every time with no binary cache; CI always clean-builds.

Fix: Use vcpkg binary cache and Conan remotes; split dependency caching in CI.

---

Table of contents

1. Getting started with vcpkg
2. Advanced vcpkg
3. Complete vcpkg example
4. Getting started with Conan
5. Advanced Conan
6. Complete Conan example
7. Comparison and choice
8. Common errors and fixes
9. Best practices
10. Production patterns

---

1. Getting started with vcpkg

Installation

Clone the vcpkg Git repository, then run the bootstrap script to build the vcpkg executable. On Linux/macOS use ./bootstrap-vcpkg.sh; on Windows use .\bootstrap-vcpkg.bat. Run vcpkg from that directory or add it to PATH. One install can serve many projects.

Run the following in a terminal.

# After pasting: run outside the project. After completion you get vcpkg.exe (Windows) or vcpkg (Linux/Mac)
# Linux/Mac
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh

# Windows (PowerShell or cmd)
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat

Result: The vcpkg (or vcpkg.exe) binary is created; check with ./vcpkg version.

Basic usage

vcpkg search json finds packages whose names contain “json”; vcpkg install nlohmann-json installs one. List packages with vcpkg list; remove with vcpkg remove nlohmann-json. Port names can differ from upstream (e.g. nlohmann-json), so use search to confirm the exact name.

Run the following in a terminal.

# Search
vcpkg search json

# Install
vcpkg install nlohmann-json

# List installed
vcpkg list

# Remove
vcpkg remove nlohmann-json

CMake integration

vcpkg integrate install registers a user-wide integration script. When you configure CMake with -DCMAKE_TOOLCHAIN_FILE=[vcpkg root]/scripts/buildsystems/vcpkg.cmake, find_package discovers vcpkg-installed packages and target_link_libraries pulls include and link paths. Your CMakeLists.txt can stay at “find_package + target_link_libraries” without hard-coded paths.

Run the following in a terminal.

# User integration
vcpkg integrate install

# Auto in CMakeLists.txt
# find_package(nlohmann_json REQUIRED)
# target_link_libraries(myapp PRIVATE nlohmann_json::nlohmann_json)

---

2. Advanced vcpkg

vcpkg.json (manifest mode)

In manifest mode, put vcpkg.json at the project root and declare dependencies. Use a dependencies array of package names as strings, or objects with name and features (e.g. Boost system, filesystem). When you run cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=…, vcpkg reads vcpkg.json and installs what is needed. Teammates and CI get the same graph from one file, improving reproducibility.

Example manifest:

{
  "name": "myproject",
  "version": "1.0.0",
  "dependencies": [
    "fmt",
    "spdlog",
    "nlohmann-json",
    {
      "name": "boost",
      "features": ["system", "filesystem"]
    }
  ]
}

Usage:

# From the directory that contains vcpkg.json
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=[vcpkg root]/scripts/buildsystems/vcpkg.cmake
cmake --build build

Triplets (platform selection)

A triplet names how vcpkg builds: platform, architecture, and linkage. x64-windows is Windows 64-bit, x64-linux Linux 64-bit, x64-osx macOS. x64-windows-static builds static libraries when you want a single executable with everything linked in. You can set triplets per CI vs local (e.g. CI x64-linux, dev x64-windows).

Run the following in a terminal.

# Windows 64-bit
vcpkg install fmt:x64-windows

# Linux 64-bit
vcpkg install fmt:x64-linux

# macOS
vcpkg install fmt:x64-osx

# Static libs
vcpkg install fmt:x64-windows-static

Version pinning

Use version>= for a minimum version and builtin-baseline with a commit date or hash from the vcpkg repo to lock ports to that snapshot. That avoids “9.1.0 today, 9.2.0 tomorrow, build breaks” drift. A shared baseline aligns the whole team and CI.

Example manifest:

{
  "name": "myproject",
  "version": "1.0.0",
  "dependencies": [
    {
      "name": "fmt",
      "version>=": "9.1.0"
    }
  ],
  "builtin-baseline": "2023-04-15"
}

---

3. Complete vcpkg example

Project layout

myapp-vcpkg/
├── CMakeLists.txt
├── vcpkg.json
├── src/
│   └── main.cpp
└── tests/
    └── test_main.cpp

vcpkg.json (dependency declaration)

Example manifest:

{
  "name": "myapp-vcpkg",
  "version": "1.0.0",
  "description": "Example C++ project using vcpkg",
  "dependencies": [
    "fmt",
    "spdlog",
    {
      "name": "nlohmann-json",
      "version>=": "3.11.0"
    },
    {
      "name": "boost-asio",
      "features": [ssl]
    }
  ],
  "builtin-baseline": "a1c7f64"
}

CMakeLists.txt

CMake example:

cmake_minimum_required(VERSION 3.15)
project(MyAppVcpkg LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)

# With the vcpkg toolchain, find_package resolves vcpkg install paths
find_package(fmt REQUIRED)
find_package(spdlog REQUIRED)
find_package(nlohmann_json REQUIRED)
find_package(Boost REQUIRED COMPONENTS system)

add_executable(myapp src/main.cpp)
target_link_libraries(myapp PRIVATE
    fmt::fmt
    spdlog::spdlog
    nlohmann_json::nlohmann_json
    Boost::system
)

src/main.cpp (runnable example)

#include <iostream>
#include <fmt/core.h>
#include <spdlog/spdlog.h>
#include <nlohmann/json.hpp>
#include <boost/asio.hpp>

int main() {
    spdlog::info("vcpkg example start");

    // fmt
    std::cout << fmt::format("Hello, {}!\n", "vcpkg");

    // nlohmann-json
    auto j = nlohmann::json::parse(R"({"name": "myapp", "version": 1})");
    std::cout << "JSON: " << j.dump() << "\n";

    // Boost.Asio (timer only)
    boost::asio::io_context io;
    boost::asio::steady_timer t(io, boost::asio::chrono::seconds(1));
    t.async_wait( { spdlog::info("timer done"); });
    io.run();

    return 0;
}

Build commands

Run the following in a terminal.

# Set VCPKG_ROOT to your vcpkg install path
export VCPKG_ROOT=/path/to/vcpkg

cmake -B build -S . \
  -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake

cmake --build build
./build/myapp

---

4. Getting started with Conan

Installation

pip install conan

conan --version

Basic usage

conan profile detect —force detects your environment (OS, compiler, arch) and creates a default profile. In conanfile.txt, put packages under [requires], and add CMakeDeps and CMakeToolchain under [generators]. conan install . —build=missing installs dependencies and generates CMake files (e.g. conan_toolchain.cmake). —build=missing builds a recipe if it is not in the cache.

Run the following in a terminal.

conan profile detect --force

conan search fmt -r conancenter

conan install . --build=missing

conanfile.txt example

INI example:

[requires]
fmt/9.1.0
spdlog/1.11.0

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

CMake integration

Run conan install first so conan_toolchain.cmake appears under your build directory. Pass -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake at configure time so find_package(fmt) resolves Conan-installed packages. vcpkg can read a manifest from the toolchain alone; Conan usually requires conan install first—document that order in scripts or README.

CMake example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

# Conan toolchain (after conan install, e.g. build/conan_toolchain.cmake)
set(CMAKE_TOOLCHAIN_FILE "${CMAKE_BINARY_DIR}/conan_toolchain.cmake" CACHE PATH "" FORCE)

find_package(fmt REQUIRED)
find_package(spdlog REQUIRED)

add_executable(myapp main.cpp)
target_link_libraries(myapp PRIVATE
    fmt::fmt
    spdlog::spdlog
)

Build:

Run the following in a terminal.

# 1. Dependencies first
conan install . --build=missing

# 2. CMake
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake
cmake --build build

---

5. Advanced Conan

conanfile.py

conanfile.py drives dependencies, build, and packaging in Python. In requirements(), call self.requires() for runtime deps; in build_requirements(), use self.test_requires() for test-only deps (e.g. GTest). layout() sets source/build layout; generate() emits CMakeToolchain for CMake. build() runs CMake(self).configure().build(). Prefer conanfile.py when you need options or conditional dependencies.

from conan import ConanFile
from conan.tools.cmake import CMake, CMakeToolchain, cmake_layout

class MyProjectConan(ConanFile):
    name = "myproject"
    version = "1.0.0"

    settings = "os", "compiler", "build_type", "arch"

    def requirements(self):
        self.requires("fmt/9.1.0")
        self.requires("spdlog/1.11.0")
        self.requires("boost/1.81.0")

    def build_requirements(self):
        self.test_requires("gtest/1.12.1")

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

Options and settings

options define per-package switches: e.g. shared for dynamic vs static, with_tests to enable test builds. Set default_options, and branch in requirements() (e.g. if self.options.with_tests:) to add test_requires conditionally. Override from the CLI: conan install . -o with_tests=False—useful to skip tests in CI.

from conan import ConanFile

class MyProjectConan(ConanFile):
    options = {
        "shared": [True, False],
        "with_tests": [True, False]
    }
    default_options = {
        "shared": False,
        "with_tests": True
    }

    def requirements(self):
        self.requires("fmt/9.1.0")

        if self.options.with_tests:
            self.test_requires("gtest/1.12.1")

Custom profiles

Profile files under [settings] pin OS, arch, compiler, standard library, build type, etc. Store them under ~/.conan2/profiles/ (e.g. gcc11) and run conan install . —profile=gcc11. [conf] can switch the CMake generator to Ninja and more—one profile can encode a team standard (e.g. Ubuntu 22.04 + GCC 11 + Release).

INI example:

# ~/.conan2/profiles/gcc11
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release

[conf]
tools.cmake.cmaketoolchain:generator=Ninja

Usage:

conan install . --profile=gcc11 --build=missing

---

6. Complete Conan example

Project layout

myapp-conan/
├── CMakeLists.txt
├── conanfile.txt
├── src/
│   └── main.cpp
└── tests/
    └── test_main.cpp

conanfile.txt

INI example:

[requires]
fmt/9.1.0
spdlog/1.11.0
nlohmann_json/3.11.2
boost/1.81.0

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

CMakeLists.txt

CMake example:

cmake_minimum_required(VERSION 3.15)
project(MyAppConan LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)

# Toolchain generated by conan install
find_package(fmt REQUIRED)
find_package(spdlog REQUIRED)
find_package(nlohmann_json REQUIRED)
find_package(Boost REQUIRED COMPONENTS system)

add_executable(myapp src/main.cpp)
target_link_libraries(myapp PRIVATE
    fmt::fmt
    spdlog::spdlog
    nlohmann_json::nlohmann_json
    Boost::system
)

src/main.cpp

#include <iostream>
#include <fmt/core.h>
#include <spdlog/spdlog.h>
#include <nlohmann/json.hpp>
#include <boost/asio.hpp>

int main() {
    spdlog::info("Conan example start");

    std::cout << fmt::format("Hello, {}!\n", "Conan");

    auto j = nlohmann::json::parse(R"({"name": "myapp", "version": 1})");
    std::cout << "JSON: " << j.dump() << "\n";

    boost::asio::io_context io;
    boost::asio::steady_timer t(io, boost::asio::chrono::seconds(1));
    t.async_wait( { spdlog::info("timer done"); });
    io.run();

    return 0;
}

Build script (build.sh)

Run the following in a terminal.

#!/bin/bash
set -e

# 1. Conan dependencies
conan install . --output-folder=build --build=missing

# 2. CMake configure & build
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake
cmake --build build

echo "Build done. Run: ./build/myapp"

---

7. Comparison and choice

vcpkg vs Conan (detailed)

Mermaid example:

flowchart TB
  subgraph vcpkg[vcpkg]
    V1[Git clone install]
    V2[Manifest: vcpkg.json]
    V3[Triplet: x64-windows]
    V4[CMake auto integration]
  end
  subgraph conan[Conan]
    C1[pip install]
    C2[conanfile.txt / .py]
    C3[Profile: compiler, build_type]
    C4[Run conan install first]
  end
  V2 --> V4
  C2 --> C4 --> C4

Aspect	vcpkg	Conan
Install	Git clone + bootstrap	pip install conan
Library count	2000+ (Microsoft ports)	1500+ (Conan Center)
CMake	Pass toolchain; manifest auto	conan install → toolchain
Versions	builtin-baseline, version>=	Explicit (fmt/9.1.0)
Build config	Triplets (x64-windows, etc.)	Profiles (compiler, build_type)
Learning curve	Easier	Medium
Flexibility	Medium	High (Python)
Binary cache	vcpkg binary cache	Conan remotes
Cross-compile	Triplets	Profiles

When to choose which

Prefer vcpkg:

• CMake-centric projects
• You want a fast start
• Microsoft stack (Visual Studio, Azure)
• Team is C++-only

Prefer Conan:

• Complex dependency graphs (conditionals, options)
• Fine-grained build control
• Team is comfortable with Python
• You need to publish your own packages

---

8. Common errors and fixes

Error 1: “Could not find a package configuration file”

CMake Error at CMakeLists.txt:10 (find_package):
  Could not find a package configuration file provided by "fmt"

Cause: vcpkg/Conan toolchain not passed to CMake, or conan install was not run.

Fix:

Run the following in a terminal.

# vcpkg
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake

# Conan: run conan install first
conan install . --build=missing
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake

Error 2: “undefined reference to” link errors

undefined reference to `fmt::v9::format(...)'

Cause: find_package worked but target_link_libraries omits the target, or Debug/Release mismatch.

Fix:

# Always link imported targets
target_link_libraries(myapp PRIVATE fmt::fmt)

# vcpkg: triplet consistency (x64-windows vs x64-windows-static)
# Conan: profile build_type matches Debug/Release

Error 3: “Version conflict” (Conan)

ERROR: Version conflict: fmt/10.0.0, fmt/9.1.0

Cause: Different recipes require different fmt versions.

Fix: Unify on one version in the Conan file, or force with overrides:

INI example:

[requires]
fmt/9.1.0
spdlog/1.11.0

[tool_requires]
# In conanfile.py: self.requires("fmt/9.1.0", override=True)

Error 4: vcpkg “Baseline must be a valid git commit”

Error: builtin-baseline must be a valid git commit

Cause: Invalid date or hash in builtin-baseline.

Fix: Use a real commit from the vcpkg repo:

cd vcpkg
git log -1 --format=%H

{
  "builtin-baseline": "a1c7f64b3"
}

Error 5: “Package not found” (Conan)

ERROR: Package 'xyz/1.0' not found

Cause: Recipe not on Conan Center, or typo in name/version.

Fix:

conan search xyz -r conancenter

# vcpkg port names can differ (e.g. nlohmann-json vs nlohmann_json)

Error 6: “A suitable version of cmake was not found”

Cause: Conan requires a newer CMake than installed.

Fix:

[tool_requires]
cmake/3.25.0

---

9. Best practices

1. Commit dependency files

Commit vcpkg.json, conanfile.txt, and conanfile.py so teammates and CI share the same graph.

2. Pin versions

Example:

// vcpkg: builtin-baseline + version>=
{
  "builtin-baseline": "a1c7f64",
  "dependencies": [{ "name": "fmt", "version>=": "9.1.0" }]
}

; Conan: explicit versions
[requires]
fmt/9.1.0

3. Minimal dependencies

Request only what you need—e.g. boost-asio and boost-system instead of all of Boost.

4. Cache in CI

Example:

# GitHub Actions (vcpkg)
- uses: actions/cache@v4
  with:
    path: ${{ env.VCPKG_ROOT }}/installed
    key: vcpkg-${{ runner.os }}-${{ hashFiles('vcpkg.json') }}

5. Match local and CI

Use the same triplet (vcpkg) or profile (Conan). If local is x64-windows, CI should use x64-windows too.

6. Fix build order for Conan

# build.sh
conan install . --build=missing
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake
cmake --build build

---

10. Production patterns

Pattern 1: Monorepo + manifest mode

For multiple subprojects, use one root vcpkg.json or per-service manifests under each folder.

monorepo/
├── vcpkg.json          # shared deps
├── service-a/
│   ├── vcpkg.json
│   └── CMakeLists.txt
└── service-b/
    ├── vcpkg.json
    └── CMakeLists.txt

Pattern 2: Pin the environment with Docker

Example:

# Dockerfile.build
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y cmake g++ git python3-pip
RUN git clone https://github.com/Microsoft/vcpkg.git /vcpkg && \
    /vcpkg/bootstrap-vcpkg.sh
ENV VCPKG_ROOT=/vcpkg
WORKDIR /app
COPY . .
RUN cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake && \
    cmake --build build

Pattern 3: Speed up CI with binary cache

vcpkg: --x-use-binary-cache or Azure Artifacts integration

vcpkg install fmt --x-binarysource=clear;default

Conan: remote cache or Artifactory

conan remote add mycache https://my-artifactory.com/conan
conan upload "*" -r mycache --all

Pattern 4: Share profiles/triplets

Commit profile files so everyone uses the same compiler and flags.

conan/
├── profiles/
│   ├── linux-gcc11
│   ├── windows-msvc2022
│   └── macos-clang14

conan install . --profile=conan/profiles/linux-gcc11

Pattern 5: Dependency update workflow

1. Bump builtin-baseline (vcpkg) or versions (Conan)
2. Build and test locally
3. Confirm CI
4. Commit

---

Hands-on recap

Project layout

myproject/
├── CMakeLists.txt
├── vcpkg.json          # if using vcpkg
├── conanfile.txt       # if using Conan
├── src/
│   └── main.cpp
└── tests/
    └── test_main.cpp

vcpkg.json

Example:

{
  "name": "myproject",
  "version": "1.0.0",
  "dependencies": [
    "fmt",
    "spdlog",
    "nlohmann-json",
    "gtest"
  ]
}

conanfile.txt

INI example:

[requires]
fmt/9.1.0
spdlog/1.11.0
nlohmann_json/3.11.2

[test_requires]
gtest/1.12.1

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

find_package(fmt REQUIRED)
find_package(spdlog REQUIRED)
find_package(nlohmann_json REQUIRED)

add_executable(myapp src/main.cpp)
target_link_libraries(myapp PRIVATE
    fmt::fmt
    spdlog::spdlog
    nlohmann_json::nlohmann_json
)

if(BUILD_TESTS)
    find_package(GTest REQUIRED)
    enable_testing()

    add_executable(myapp_test tests/test_main.cpp)
    target_link_libraries(myapp_test PRIVATE GTest::gtest_main)

    add_test(NAME myapp_test COMMAND myapp_test)
endif()

---

Implementation checklist

• Install vcpkg or Conan
• Add vcpkg.json or conanfile.txt
• Set builtin-baseline (vcpkg) or explicit versions (Conan)
• Pass toolchain file to CMake
• Add every dependency to target_link_libraries
• Use the same toolchain/profile in CI
• Optionally configure dependency caches

---

Related posts (internal links)

• Advanced CMake for C++: multi-target projects and external libraries
• CMake intro: automating builds with CMakeLists.txt
• C++ environment setup: compiler install through Hello World

---

Keywords

Search terms such as C++ package manager, vcpkg, Conan, dependency management, and library installation lead to topics covered here.

Summary

Task	vcpkg	Conan
Install	vcpkg install fmt	conan install .
Dependency file	vcpkg.json	conanfile.txt / conanfile.py
CMake	Toolchain + auto manifest	conan install → toolchain
Pinning	Baseline + version>=	Explicit versions

Principles:

1. Use a package manager
2. Declare dependencies in files
3. Pin versions for reproducibility
4. Integrate with CI/CD
5. Pick the tool that fits the project

FAQ

Q. When do I use this in production?

A. Whenever you install C++ libraries with vcpkg or Conan, manage project dependencies, and need reproducible builds. Apply the examples and selection guide above.

Q. What should I read first?

A. Follow Previous post links at the bottom of each article for order. See the C++ series index for the full path.

Q. Where can I go deeper?

A. Use cppreference and each library’s official docs. Use the reference links at the end of this post as well.

One-line summary: With vcpkg and Conan you declare external libraries and automate install and linking.

Next: Google Test (#18-1)

Previous: Advanced CMake (#17-1): large-project build systems

---

See also

• Advanced CMake for C++
• C++ iterator basics
• Custom iterators in C++
• Package management deep dive (#55-6)
• vcpkg basics (#53-3)