Package management — vcpkg আর Conan দিয়ে বাইরের লাইব্রেরি আনা

১ · “লাইব্রেরিটা শুধু নামিয়ে নিই” — C++-এ কেন এত সহজ নয়

Python শেখার সময় আপনি হয়তো pip install requests লিখেছেন, আর পরের লাইনেই import requests. Java-তে Maven-এর ফাইলে একটি লাইন যোগ করলেই লাইব্রেরি চলে আসে। JavaScript-এ npm, Rust-এ cargo. সব আধুনিক ভাষার একটি নিজস্ব package manager আছে, যা ভাষার সাথেই আসে।

C++ এভাবে বড় হয়নি — কোনো “অফিসিয়াল” লাইব্রেরি-বাজার তৈরি হয়নি। এর পেছনে একটি প্রযুক্তিগত কারণও আছে, আর সেটা বুঝলেই এই পর্বের বাকিটা সহজ।

লাইব্রেরি তিন রকম চেহারায় আসে

শেষ দুই ধরনে লাইব্রেরি আসে machine code হিসেবে। আর machine code-এর সাথে আপনার কোড জোড়া লাগবে কি না, তা ঠিক করে একটি অদৃশ্য চুক্তি — ABI (Application Binary Interface). পর্ব ০৩-এ দেখেছেন, C++ compiler প্রতিটি ফাংশনের নাম বদলে একটি লম্বা চিহ্ন বানায় — name mangling. GCC আর MSVC এই কাজ ভিন্ন নিয়মে করে। শুধু নাম নয়, ABI-তে আরও অনেক কিছু থাকে:

নিজের মেশিনের এই “মাপ” একটি ছোট প্রোগ্রাম দিয়েই দেখা যায়। নিচের কোড compiler, standard library আর build ধরন নিজেই জানিয়ে দেয় — ঠিক যে তথ্যগুলো একটি package manager লাইব্রেরি build করার আগে মিলিয়ে নেয়:

#include <print>
#include <version>
int main() {
#if defined(__clang__)
    std::println("compiler        : Clang");
#elif defined(__GNUC__)
    std::println("compiler        : GCC");
#endif
#if defined(__GLIBCXX__)
    std::println("standard library: libstdc++ (new string ABI = {})", _GLIBCXX_USE_CXX11_ABI);
#elif defined(_LIBCPP_VERSION)
    std::println("standard library: libc++");
#endif
#ifdef NDEBUG
    std::println("build style     : Release (NDEBUG defined)");
#else
    std::println("build style     : Debug (NDEBUG not defined)");
#endif
    std::println("sizeof(long)    : {} bytes", sizeof(long));
}

এখন একটি বাস্তব দুর্ঘটনা ধাপে ধাপে দেখুন। রাফি একটি দোকানের হিসাবের প্রোগ্রাম লিখছেন, আর এক সহকর্মী তাঁকে ইমেইলে একটি আগে-build-করা fmt লাইব্রেরি পাঠিয়েছেন:

fmt/
├── include/fmt/format.h
└── lib/fmt.lib      # কোন compiler? কোন build type? লেখা নেই
# আসলে: Visual Studio 2022, Release, /MD দিয়ে বানানো

undefined reference to `fmt::v10::vformat(fmt::v10::basic_string_view<char>, ...)'
# g++ খুঁজছে _ZN3fmt3v107vformat... নামের চিহ্ন
# fmt.lib-এ আছে ?vformat@v10@fmt@@... (MSVC-র mangling)

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL':
  value '0' doesn't match value '2' in main.obj
error LNK2038: mismatch detected for 'RuntimeLibrary':
  value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug'

undefined reference to `report::save(std::__cxx11::basic_string<char> const&)'
# আপনার কোড নতুন ABI-র std::string চায় (__cxx11)
# লাইব্রেরিটি _GLIBCXX_USE_CXX11_ABI=0 দিয়ে বানানো

vcpkg : triplet  x64-windows  → Debug আর Release দুই কপিই বানায়
Conan : profile  compiler=msvc, build_type=Debug
# লাইব্রেরি আপনার compiler, runtime আর build type দিয়েই তৈরি
# ফলে link-এ কোনো অমিল নেই

২ · পুরোনো পথগুলো — source কপি, apt/brew আর “dependency hell”

Package manager আসার আগে C++ দলগুলো তিনটি পথে বাইরের লাইব্রেরি আনত। তিনটিই আজও দেখা যায়, তাই এদের সুবিধা আর সীমা জানা দরকার।

পথ ১ — source কপি করে repository-তে রাখা

লাইব্রেরির পুরো source নিজের প্রজেক্টের third_party/ ফোল্ডারে কপি করে Git-এ রেখে দেওয়া — এর নাম vendoring. সুবিধা: ইন্টারনেট ছাড়াই build হয়। খরচ: নিরাপত্তা-ত্রুটির খবর নিজে রাখতে হয়, নতুন version হাতে কপি করতে হয়, আর কপি করা কোডে কেউ “ছোট একটা ঠিক” করে দিলে পরে আপডেট প্রায় অসম্ভব। ছোট header-only লাইব্রেরির জন্য এটা এখনও যুক্তিসংগত; বড় লাইব্রেরির জন্য নয়।

পথ ২ — অপারেটিং সিস্টেমের package manager

sudo apt install libfmt-dev libspdlog-dev   # Ubuntu / Debian
brew install fmt spdlog                       # macOS (Homebrew)

Linux-এর apt, dnf বা macOS-এর Homebrew-কে বলে system package manager. এরা লাইব্রেরি আপনার সিস্টেমের compiler দিয়ে আগেই build করে রাখে, তাই ABI মিলে যায়, আর find_package সহজেই খুঁজে পায়। সীমা তিনটি:

• একটিই version: পুরো সিস্টেমে প্রতিটি লাইব্রেরির একটি কপি। দুটি প্রজেক্টের দুটি ভিন্ন version লাগলে বিপদ।
• Version আপনার হাতে নয়: Ubuntu-র একটি পুরোনো রিলিজে fmt পুরোনো, Arch-এ নতুন। দলের দুজনের মেশিনে দুই version — “আমার মেশিনে তো চলে!”
• Windows-এ নেই: Windows-এর কোনো সর্বজনীন system package manager C++ লাইব্রেরি এভাবে দেয় না।

পথ ৩ — হাতে build করে কোথাও বসানো

লাইব্রেরির source নামিয়ে নিজে CMake চালিয়ে build আর install করা, তারপর সেই ফোল্ডার CMAKE_PREFIX_PATH-এ দেওয়া। কাজ করে, কিন্তু প্রতিটি নতুন মেশিন আর version-এ একই কাজ আবার। আর লাইব্রেরির নিজেরও নির্ভরতা থাকে — spdlog নিজেই fmt-এর ওপর নির্ভর করতে পারে। এই transitive dependency-গুলো হাতে মেলাতে গিয়েই জন্ম নেয় বিখ্যাত dependency hell.

Dependency hell-এর সবচেয়ে পরিচিত রূপ হলো diamond dependency: আপনার প্রোগ্রাম দুটি লাইব্রেরি ব্যবহার করে, আর দুজনেই তৃতীয় একটি লাইব্রেরির ওপর নির্ভর করে — কিন্তু ভিন্ন version-এ। নিচে ধাপে ধাপে দেখুন:

shop_app
├── spdlog      # logging
└── old_report  # পুরোনো রিপোর্ট লাইব্রেরি, অন্য দলের লেখা
# দুজনেরই ভেতরে fmt লাগে

spdlog 1.13 ──► fmt 10.x
# spdlog-এর header-এ fmt-এর টাইপ সরাসরি ব্যবহৃত হয়

old_report 2.1 ──► fmt 8.x
# fmt 9-এ কিছু পুরোনো API বদলেছে, old_report আর আপডেট হয়নি

fmt::v10::vformat  বনাম  fmt::v8::vformat
# দুটোই link করলে: একই header দুইবার, ভিন্ন সংজ্ঞা
# ফল: compile error, অথবা চুপচাপ ODR ভঙ্গ — undefined behavior

১. old_report-কে fmt 10-এ আপডেট করা   # সবচেয়ে ভালো
২. old_report-এর নতুন version খোঁজা
৩. vcpkg "overrides" / Conan "override" দিয়ে একটি version বাঁধা
   (তারপর পুরো টেস্ট চালানো বাধ্যতামূলক)

৩ · বিকল্পের মানচিত্র — FetchContent, CPM, vcpkg, Conan

পর্ব ৪৯-এ আপনি CMake-এর তিনটি পথ দেখেছেন: find_package দিয়ে আগে থেকে বসানো লাইব্রেরি খোঁজা, FetchContent দিয়ে configure-এর সময় source নামানো, আর এক অনুচ্ছেদে vcpkg. এই পর্ব তৃতীয় পথটি গভীরে দেখবে। তার আগে পুরো মানচিত্রটা এক জায়গায়।

FetchContent-এর ওপর একটি জনপ্রিয় ছোট মোড়ক আছে — CPM.cmake. এটি একটি মাত্র .cmake ফাইল, যা প্রজেক্টে রাখলে এক লাইনে লাইব্রেরি আনা যায়, আর একই source একাধিক build ফোল্ডারে বারবার না নামিয়ে একটি cache-এ রাখা যায়:

include(cmake/CPM.cmake)
CPMAddPackage("gh:fmtlib/fmt#10.2.1")       # GitHub-এর fmtlib/fmt, tag 10.2.1
target_link_libraries(shop_core PRIVATE fmt::fmt)

FetchContent আর CPM দুটোই “source dependency”: লাইব্রেরি আপনার প্রজেক্টের অংশ হিসেবে, আপনার compiler আর flag দিয়েই build হয়। তাই ABI-র সমস্যা প্রায় থাকে না। কিন্তু প্রতিটি পরিষ্কার build-এ সব নির্ভরতা আবার compile হয়, আর লাইব্রেরিকে নিজেই CMake-বন্ধু হতে হয়। Boost, Qt বা OpenSSL-এর মতো বড় বা CMake-ছাড়া লাইব্রেরির জন্য এটা কষ্টকর।

৪ · vcpkg — একটি vcpkg.json আর একটি baseline

vcpkg Microsoft-এর তৈরি, open source (MIT লাইসেন্স), আর Windows, Linux, macOS তিনটিতেই চলে। এর registry-তে দুই হাজারের বেশি লাইব্রেরির রেসিপি আছে, প্রতিটিকে বলে একটি port. vcpkg মূলত source থেকে, আপনার মেশিনে, আপনার compiler দিয়ে লাইব্রেরি build করে — ABI মেলানোর সবচেয়ে নিশ্চিত উপায়।

এককালীন বসানো

git clone https://github.com/microsoft/vcpkg.git
cd vcpkg && ./bootstrap-vcpkg.sh       # Windows-এ: .\bootstrap-vcpkg.bat
export VCPKG_ROOT="$PWD"                 # vcpkg কোথায় আছে, সবাইকে জানানো

Visual Studio 2022-এর সাম্প্রতিক সংস্করণে vcpkg আগে থেকেই থাকে, আর GitHub Actions-এর তৈরি runner-গুলোতেও। তবে নিজের ক্লোন রাখলে কোন commit ব্যবহার হচ্ছে তা আপনার নিয়ন্ত্রণে থাকে।

Manifest mode — প্রজেক্টের নির্ভরতা প্রজেক্টের ফাইলে

পুরোনো দিনে vcpkg-এ vcpkg install fmt লিখে পুরো মেশিনের জন্য লাইব্রেরি বসানো হতো (classic mode). আধুনিক পদ্ধতি manifest mode: প্রজেক্টের মূল ফোল্ডারে একটি vcpkg.json, যা Git-এ থাকে। রাকিবের দোকানের প্রজেক্টের জন্য:

{
  "name": "shop",
  "version": "1.0.0",
  "dependencies": [
    "fmt",
    { "name": "spdlog", "version>=": "1.13.0" },
    "nlohmann-json",
    "gtest"
  ],
  "builtin-baseline": "0123456789abcdef0123456789abcdef01234567"
}

Baseline হলো vcpkg-এর সবচেয়ে চতুর ধারণা। এক commit মানে পুরো লাইব্রেরি-জগতের একটি “ছবি”, যেখানে সব port একসাথে পরীক্ষা করা হয়েছে। আপনি baseline না বদলালে কখনো version বদলাবে না; baseline আপডেট করা একটি সচেতন সিদ্ধান্ত, যা একটি Git commit হয়ে রিভিউতে যায়। কোনো নির্দিষ্ট লাইব্রেরি পুরোনো রাখতে চাইলে আছে overrides, আর লাইব্রেরির ঐচ্ছিক অংশ চাইলে features:

{
  "dependencies": [ "fmt", { "name": "curl", "features": [ "ssl" ] } ],
  "overrides": [ { "name": "fmt", "version": "10.2.1" } ],
  "builtin-baseline": "0123456789abcdef0123456789abcdef01234567"
}

CMake-কে vcpkg চেনানো — toolchain file আর preset

vcpkg CMake-এর সাথে জোড়া লাগে একটি toolchain file দিয়ে। পর্ব ৪৯-এর CMakePresets.json-এ এটা একবার লিখে রাখাই সবচেয়ে পরিষ্কার:

{
  "version": 6,
  "configurePresets": [
    {
      "name": "vcpkg-debug",
      "generator": "Ninja",
      "binaryDir": "build/debug",
      "toolchainFile": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" }
    }
  ]
}

পুরোনো ধাঁচে একই কাজ কমান্ড-লাইনে: cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake. এবার শুধু cmake --preset vcpkg-debug চালালে ভেতরে কী কী ঘটে, ধাপে ধাপে দেখুন:

-- Running vcpkg install
# প্রথম project() ডাকের শুরুতেই vcpkg.cmake দেখে: পাশে vcpkg.json আছে?
# আছে → manifest mode. চাহিদা: fmt, spdlog>=1.13.0, nlohmann-json, gtest

The following packages will be built and installed:
    fmt:x64-linux@10.2.1          # spdlog-এর নির্ভরতা হিসেবেও
    gtest:x64-linux@1.14.0
    nlohmann-json:x64-linux@3.11.3
    spdlog:x64-linux@1.13.0
# সংখ্যাগুলো উদাহরণ — আপনার baseline ঠিক করবে

Detecting compiler hash for triplet x64-linux...
Restored 2 package(s) from ~/.cache/vcpkg/archives
# fmt আর nlohmann-json আগের কোনো প্রজেক্টে একই সেটিংয়ে বানানো ছিল
# gtest আর spdlog নতুন — এগুলো build হবে

Building gtest:x64-linux@1.14.0...
-- Downloading https://github.com/google/googletest/archive/v1.14.0.tar.gz
-- SHA512 মিলেছে, extracting...
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Installing ... Stored binaries in 1 destinations

vcpkg_installed/x64-linux/
├── include/   fmt/  spdlog/  nlohmann/  gtest/
├── lib/       libfmt.a  libspdlog.a  libgtest.a ...
├── debug/lib/ libfmtd.a ...          # Debug কপি
└── share/     fmt/fmt-config.cmake ...  # CMake-এর জন্য

find_package(fmt CONFIG REQUIRED)    # share/fmt/fmt-config.cmake পায়
target_link_libraries(shop_core PRIVATE fmt::fmt)
-- Configuring done
-- Generating done

Triplet — “কোন মাপের বোতাম”

Triplet হলো vcpkg-এর ভাষায় ABI-র বর্ণনা: আর্কিটেকচার, প্ল্যাটফর্ম, আর লাইব্রেরি static না dynamic. নামটা পুরোনো “target triple” থেকে এসেছে। প্রচলিত কয়েকটি:

Triplet বাছতে CMake-এ VCPKG_TARGET_TRIPLET variable দিন (preset-এর cacheVariables-এ)। অংশ ১-এর /MT বনাম /MD সমস্যাটা মনে আছে? x64-windows-static বাছলে আপনার নিজের প্রোগ্রামকেও static CRT-তে build করতে হয় — CMake-এ CMAKE_MSVC_RUNTIME_LIBRARY দিয়ে। Triplet বদলানো মানে ABI বদলানো; তাই এটা দলের সবার জন্য preset-এ লিখে রাখুন, প্রত্যেকের ইচ্ছামতো নয়।

৫ · দলের জন্য vcpkg — binary cache, overlay port আর নিজস্ব registry

একা কাজ করলে উপরের টুকুই যথেষ্ট। দল আর CI এলে তিনটি প্রশ্ন ওঠে: প্রতিটি মেশিনে কি একই লাইব্রেরি আবার compile হবে? কোম্পানির নিজস্ব লাইব্রেরি কোথায় থাকবে? আর public registry-র কোনো port-এ ছোট বদল লাগলে কী করব?

Binary cache ভাগ করা

vcpkg ডিফল্টভাবে নিজের মেশিনে একটি ফোল্ডারে cache রাখে (Linux-এ সাধারণত ~/.cache/vcpkg/archives, Windows-এ %LOCALAPPDATA%\vcpkg\archives). দলের জন্য VCPKG_BINARY_SOURCES environment variable দিয়ে একটি ভাগ করা জায়গা দেওয়া যায় — একটি network ফোল্ডার, একটি NuGet feed, বা cloud storage. Cache-এর চাবি সেই ABI hash, তাই ভুল ABI-র binary ভুল মেশিনে যায় না।

# নিজের network ফোল্ডারকে cache বানানো (পড়া ও লেখা দুটোই)
export VCPKG_BINARY_SOURCES="clear;files,/mnt/team-cache/vcpkg,readwrite"

Overlay port — নিজের রেসিপি

কোম্পানির নিজের লাইব্রেরি, ধরা যাক bkash-sdk-internal, public registry-তে নেই। বা public fmt port-এ একটি patch দরকার। তখন প্রজেক্টে একটি ports/ ফোল্ডারে নিজের port লিখুন — প্রতিটি port মানে একটি ফোল্ডার, তাতে একটি vcpkg.json আর একটি portfile.cmake (কোথা থেকে source আসবে, কীভাবে build হবে)। এর নাম overlay port: একই নামের public port-কে এটি “ঢেকে” দেয়।

{
  "default-registry": {
    "kind": "git",
    "repository": "https://github.com/microsoft/vcpkg",
    "baseline": "0123456789abcdef0123456789abcdef01234567"
  },
  "overlay-ports": [ "./ports" ]
}

অনেকগুলো প্রজেক্টে একই অভ্যন্তরীণ লাইব্রেরি লাগলে overlay-র বদলে কোম্পানির একটি নিজস্ব Git registry বানানো ভালো — তাতে ports আর version-এর ইতিহাস থাকে, আর vcpkg-configuration.json-এর registries অংশে লিখে দিলে নির্দিষ্ট package-গুলো সেখান থেকে আসে। লক্ষ করুন, এই ফাইলেও baseline আছে; নতুন প্রজেক্টে vcpkg new --application চালালে vcpkg baseline-টা এখানেই লিখে দেয়।

৬ · Conan 2 — profile, conanfile আর --build=missing

Conan-এর দর্শন একটু আলাদা। vcpkg-এর মূল ভাবনা “আপনার মেশিনে source থেকে build, সাথে cache”; Conan-এর মূল ভাবনা “প্রতিটি সেটিংয়ের জন্য আলাদা binary package, সার্ভারে জমা” — না পেলে তখন build. Conan Python-এ লেখা, তাই বসানো সহজ: pip install conan. এখানে আমরা শুধু Conan 2 দেখব (২০২৩-এ এসেছে); Conan 1-এর অনেক কমান্ড আর ফাইল এতে চলে না।

Profile — আপনার ABI এক ফাইলে

প্রথমবার conan profile detect চালালে Conan আপনার compiler খুঁজে একটি ডিফল্ট profile লেখে। এটি আসলে অংশ ১-এর টেবিলটিরই লিখিত রূপ:

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=13
os=Linux

compiler.libcxx=libstdc++11 লক্ষ করুন — এটাই সেই নতুন std::string ABI (অংশ ১-এর runnable কোডের new string ABI = 1). দরকার হলে নিজের নামে আরও profile বানান, যেমন debug বা windows-msvc. compiler.cppstd-এ আপনার প্রজেক্টের standard দিন (C++23-এর জন্য 23 বা gnu23, যদি আপনার Conan সংস্করণ আর compiler সমর্থন করে)।

conanfile — কী লাগবে

সরল প্রজেক্টে একটি conanfile.txt:

[requires]
fmt/10.2.1
spdlog/1.13.0
nlohmann_json/3.11.3

[test_requires]
gtest/1.14.0

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

Conan-এ version সাধারণত হুবহু লেখা হয় (fmt/10.2.1); version range-ও আছে (fmt/[>=10 <11]). Package-এর নামও vcpkg থেকে আলাদা হতে পারে: Conan-এ nlohmann_json, vcpkg-এ nlohmann-json. শর্ত বা যুক্তি লাগলে (যেমন “শুধু Windows-এ এই লাইব্রেরি”) Python-এ conanfile.py:

from conan import ConanFile
from conan.tools.cmake import cmake_layout

class ShopRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeDeps", "CMakeToolchain"

    def requirements(self):
        self.requires("fmt/10.2.1")
        self.requires("spdlog/1.13.0")
        if self.settings.os == "Windows":
            self.requires("openssl/[>=3 <4]")   # Linux-এ সিস্টেমের OpenSSL, Windows-এ Conan থেকে

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

    def layout(self):
        cmake_layout(self)

প্রথম লাইনটি খেয়াল করুন: Conan 2-এ from conan import ConanFile. Conan 1-এ ছিল from conans import ConanFile (শেষে “s”) — AI প্রায়ই এটা মিশিয়ে ফেলে।

Install থেকে build — পুরো প্রবাহ

conan profile detect --force               # একবার: ডিফল্ট profile
conan install . --build=missing            # নির্ভরতা আনা/বানানো + CMake ফাইল লেখা
cmake --preset conan-release               # configure (Conan-এর বানানো preset)
cmake --build --preset conan-release       # build

profile : os=Linux, compiler=gcc 13, libcxx=libstdc++11, build_type=Release
conanfile.txt : fmt/10.2.1, spdlog/1.13.0, nlohmann_json/3.11.3
                gtest/1.14.0 (শুধু টেস্টের জন্য)

======== Computing dependency graph ========
Requirements
    fmt/10.2.1#...         - Downloaded (conancenter)
    spdlog/1.13.0#...      - Downloaded (conancenter)
# spdlog-এর নিজের চাহিদা fmt — একই fmt/10.2.1-এ মিলেছে

fmt/10.2.1     package_id a1b2…  # gcc13 + Release + libstdc++11-এর hash
               → conancenter-এ আছে → Download
spdlog/1.13.0  package_id c3d4…
               → এই সেটিংয়ের binary নেই → Missing

ERROR: Missing prebuilt package for 'spdlog/1.13.0'
# --build=missing দিলে:
spdlog/1.13.0: Building from source...
spdlog/1.13.0: Package c3d4… created  # লোকাল cache-এ জমা

conan_toolchain.cmake       # CMakeToolchain: compiler, flag, prefix path
fmt-config.cmake            # CMakeDeps: find_package(fmt) এর জন্য
spdlog-config.cmake
nlohmann_json-config.cmake
CMakePresets.json           # + প্রজেক্টে CMakeUserPresets.json

-- Using Conan toolchain: .../conan_toolchain.cmake
-- Conan: Target declared 'fmt::fmt'
-- Conan: Target declared 'spdlog::spdlog'
-- Configuring done
# $ cmake --build --preset conan-release

Lockfile আর remote — দলের অভ্যাস

Conanfile-এ হুবহু version লিখলেও একটি ফাঁক থাকে: একই version-এর রেসিপিও পরে সংশোধিত হতে পারে (Conan-এর ভাষায় নতুন “revision”), আর transitive নির্ভরতা range দিয়ে লেখা থাকলে আজ আর কাল ভিন্ন ফল আসতে পারে। তাই দলের অ্যাপ্লিকেশনের জন্য একটি lockfile বানিয়ে Git-এ রাখুন:

conan lock create .                          # conan.lock: সব version আর revision বাঁধা
conan install . --lockfile=conan.lock --build=missing

Conan package আসে remote থেকে — ডিফল্ট remote হলো ConanCenter, যেখানে কমিউনিটির রক্ষণাবেক্ষণ করা হাজারো রেসিপি আছে। অনেক কোম্পানি নিজের একটি remote চালায় (যেমন JFrog Artifactory-তে, বা open source conan_server), যেখানে তিনটি জিনিস থাকে: অভ্যন্তরীণ লাইব্রেরি, CI-তে আগে-বানানো binary, আর ConanCenter থেকে যাচাই করে আনা রেসিপির কপি।

conan remote add mycompany https://conan.example.com/artifactory/api/conan/conan-local
conan upload "shop_core/*" -r=mycompany       # নিজের package তোলা
conan remote disable conancenter              # কঠোর নীতি: শুধু যাচাই করা remote

৭ · CMake-এ লাইব্রেরি ব্যবহার — fmt, spdlog, nlohmann_json, GoogleTest, Boost

vcpkg বা Conan যেটাই হোক, আপনার CMakeLists.txt-এর কাজ একই: find_package দিয়ে খোঁজা, target_link_libraries দিয়ে জোড়া। ঝামেলা শুধু নামে — তিন জায়গায় তিন রকম নাম থাকতে পারে। নিচের টেবিল প্রচলিত লাইব্রেরিগুলোর জন্য, তবু নতুন version-এ কিছু বদলালে লাইব্রেরির নিজের ডকুমেন্টেশন বা vcpkg install-এর শেষে ছাপা “usage” লেখাটিই চূড়ান্ত:

বাস্তব উদাহরণ — ক্যাপস্টোনে fmt, spdlog আর config ফাইল

পর্ব ৫৪-এর ক্যাপস্টোন প্রজেক্টে আপনি একটি আসল C++ সিস্টেম বানাবেন। ধরা যাক, তাতে তিনটি জিনিস লাগবে: সুন্দর ফরম্যাটে আউটপুট (fmt), ফাইলে log লেখা (spdlog), আর একটি config.json থেকে সেটিং পড়া (nlohmann_json). সাথে পর্ব ৫১-এর টেস্টের জন্য GoogleTest. উপরের vcpkg.json বা conanfile.txt থাকলে CMakeLists.txt-এর প্রাসঙ্গিক অংশ:

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

add_library(shop_core STATIC src/inventory.cpp src/config.cpp)
target_link_libraries(shop_core
    PUBLIC  fmt::fmt                         # public header-এ fmt-এর টাইপ আছে
    PRIVATE spdlog::spdlog nlohmann_json::nlohmann_json)

find_package(GTest CONFIG REQUIRED)
add_executable(shop_tests tests/config_test.cpp)
target_link_libraries(shop_tests PRIVATE shop_core GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(shop_tests)

একটি লক্ষণীয় ব্যাপার: পর্ব ০৭-এ আপনি std::format আর std::println ব্যবহার করেছেন। এগুলো আসলে fmt লাইব্রেরিরই standard-রূপ — Victor Zverovich-এর fmt-এর নকশা প্রস্তাব আকারে C++20-এ std::format হয়েছে, আর C++23-এ std::print. অর্থাৎ নতুন compiler থাকলে সরল ফরম্যাটিংয়ের জন্য আর বাইরের নির্ভরতা লাগে না; পুরোনো compiler সমর্থন করতে হলে বা fmt-এর বাড়তি সুবিধা (যেমন রঙিন আউটপুট) লাগলে fmt. নিচের প্রোগ্রাম std::format দিয়েই একটি package manager-এর ছোট্ট কাজ করে দেখায় — কোন version একটি version>= শর্ত মেটায়:

#include <compare>
#include <format>
#include <print>
#include <string>
#include <vector>
struct Ver {
    int major, minor, patch;
    auto operator<=>(const Ver&) const = default;   // major, then minor, then patch
};
std::string str(Ver v) { return std::format("{}.{}.{}", v.major, v.minor, v.patch); }
int main() {
    const Ver need{10, 1, 0};                         // "version>=": "10.1.0"
    const std::vector<Ver> registry{{9, 1, 0}, {10, 1, 0}, {10, 2, 1}, {11, 0, 2}};
    std::println("{:<8} {:<4} {}", "version", ">=", "same major");
    for (Ver v : registry)
        std::println("{:<8} {:<4} {}", str(v), v >= need ? "yes" : "no",
                     v.major == need.major ? "yes" : "no");
    for (Ver v : registry)
        if (v >= need) { std::println("minimum that satisfies: {}", str(v)); break; }
}

৮ · Version, CI আর লাইসেন্স — দীর্ঘ জীবনের অভ্যাস

Semantic versioning আর version বাঁধা

বেশিরভাগ লাইব্রেরি MAJOR.MINOR.PATCH নিয়ম মানার চেষ্টা করে: PATCH মানে শুধু বাগ-ঠিক, MINOR মানে নতুন সুবিধা কিন্তু পুরোনো কোড চলবে, MAJOR মানে API ভাঙতে পারে। C++-এ একটি বাড়তি সূক্ষ্মতা আছে — API (source) সামঞ্জস্য আর ABI (binary) সামঞ্জস্য আলাদা। একটি struct-এ নতুন private সদস্য যোগ করলে আপনার কোড একটুও না বদলে compile হয়, কিন্তু struct-এর আকার বদলেছে; পুরোনো binary-র সাথে মেশালে crash. তাই C++-এ একটি minor আপডেটের পরেও সব কিছু আবার build করা নিরাপদ অভ্যাস — package manager ঠিক এটাই করে।

নিয়মটা সহজ: অ্যাপ্লিকেশনের নির্ভরতা বেঁধে রাখুন (version pinning) — vcpkg-এ baseline (আর দরকারে overrides), Conan-এ হুবহু version আর lockfile, FetchContent-এ tag বা commit hash. আপডেট হবে পরিকল্পিতভাবে: একটি আলাদা branch-এ baseline বদলানো, পুরো টেস্ট চালানো, তারপর merge. আর আপনি নিজে লাইব্রেরি লিখলে উল্টো নীতি — খুব সরু version চাইবেন না, যাতে ব্যবহারকারীর diamond সংঘাত না হয়।

CI-তে package manager

পর্ব ৫১-এ টেস্টের সাথে continuous integration-এর কথাও আসবে। এখানে শুধু package manager-এর অংশটুকু: CI মেশিন প্রতিবার নতুন, তাই cache না রাখলে প্রতিটি push-এ সব লাইব্রেরি নতুন করে compile হয়। GitHub Actions-এ vcpkg-এর একটি সরল রূপ:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.cache/vcpkg/archives
          key: vcpkg-${{ runner.os }}-${{ hashFiles('vcpkg.json', 'vcpkg-configuration.json') }}
      - run: |
          export VCPKG_ROOT="$VCPKG_INSTALLATION_ROOT"
          cmake --preset vcpkg-debug
          cmake --build build/debug
          ctest --test-dir build/debug --output-on-failure

Cache-এর চাবিতে vcpkg.json-এর hash রাখায় নির্ভরতা বদলালে নতুন cache তৈরি হয়, না বদলালে আগেরটা ফিরে আসে। বাস্তবে অনেক দল vcpkg-কে নিজের repository-তে Git submodule হিসেবে রাখে, যাতে runner-এর আগে-বসানো vcpkg-এর version-এর ওপর নির্ভর করতে না হয়। Conan-এর জন্য একই ধারণা: ~/.conan2-এর package ফোল্ডার cache করা, বা আরও ভালো, কোম্পানির নিজস্ব remote থেকে binary নামানো।

লাইসেন্স — কোড বিনামূল্যে, শর্ত বিনামূল্যে নয়

প্রতিটি নির্ভরতা একটি software license নিয়ে আসে, আর আপনার প্রোগ্রাম বিতরণ করলে সেই শর্ত মানতে হয়। এখানে সাধারণ ধারণা দেওয়া হলো — এটি আইনি পরামর্শ নয়; বাণিজ্যিক পণ্যের জন্য প্রতিষ্ঠানের আইন-বিভাগের সাথে কথা বলুন।

vcpkg প্রতিটি port-এর লাইসেন্স-লেখা vcpkg_installed/<triplet>/share/<port>/copyright-এ রাখে, আর Conan-এর conan graph info . প্রতিটি package-এর license দেখায়। নতুন নির্ভরতা যোগ করার আগে লাইসেন্স দেখা যেন version দেখার মতোই অভ্যাস হয়। বড় প্রতিষ্ঠানে এখন প্রতিটি পণ্যের সাথে সব নির্ভরতার একটি তালিকা রাখা হয় — SBOM (Software Bill of Materials); vcpkg-ও SPDX ফরম্যাটে এমন তথ্য লিখতে পারে।

৯ · নিরাপত্তা আর ভবিষ্যৎ — supply chain আর modules

প্রতিটি নির্ভরতা মানে আপনার প্রোগ্রামে অন্য কারও লেখা কোড, যা আপনার ব্যবহারকারীর মেশিনে আপনার নামে চলে। আক্রমণকারীরা তাই সরাসরি আপনাকে না আক্রমণ করে আপনার কোনো নির্ভরতাকে নিশানা করতে পারে — এর নাম supply-chain attack. ২০২৪ সালে Linux-এর বহুল ব্যবহৃত C লাইব্রেরি xz utils-এ এমন একটি backdoor ধরা পড়েছিল, যা কয়েক বছর ধরে বিশ্বাস অর্জন করা একজন “রক্ষণাবেক্ষণকারী” ঢুকিয়েছিলেন। সৌভাগ্যক্রমে সেটা ব্যাপকভাবে ছড়ানোর আগেই একজন প্রকৌশলী ছোট একটি গতির পার্থক্য দেখে ধরে ফেলেন। C আর C++-এর জগৎও তাই নিরাপদ নয়। আত্মরক্ষার অভ্যাসগুলো:

• Version বাঁধা — baseline, lockfile, commit hash. “সবসময় সর্বশেষ” মানে অন্য কেউ আপনার কোড বদলাতে পারে।
• Baseline বা lockfile আপডেট রিভিউ করা — কোন package-এর version বদলাল, নতুন কোনো transitive নির্ভরতা এল কি না।
• Hash যাচাই চালু রাখা — vcpkg-এর portfile source-এর SHA512 মেলায়, Conan রেসিপির revision রাখে; এগুলো বন্ধ করবেন না।
• কম নির্ভরতা — একটি ছোট ফাংশনের জন্য একটি পুরো লাইব্রেরি নয়; standard library-তে থাকলে সেটাই।
• প্রতিষ্ঠানে নিজস্ব mirror — Conan-এর private remote বা vcpkg-এর নিজস্ব registry আর asset cache, যেখানে শুধু যাচাই করা কপি থাকে।
• নামের বানান মিলিয়ে নেওয়া — কাছাকাছি নামের নকল package (typosquatting) public registry-তে থাকতে পারে।

ভবিষ্যৎ — modules আর import std;

পর্ব ৪৩-এ C++20 modules দেখেছেন, আর C++23-এ এসেছে import std; — পুরো standard library এক লাইনে। Packaging-এর জন্য এর মানে বড়, কিন্তু এখনো পরিবর্তনশীল। Module compile হয়ে যে BMI ফাইল বানায়, তা compiler-নির্দিষ্ট, এমনকি compiler-এর flag-নির্দিষ্ট — অর্থাৎ header-এর চেয়েও কঠোর “ABI”. তাই লাইব্রেরিগুলো module-এর source (interface ফাইল) বিতরণ করে, আর আপনার build system সেটা আপনার compiler দিয়ে compile করে। CMake এ জন্য নতুন সুবিধা যোগ করেছে, আর vcpkg ও Conan module-যুক্ত লাইব্রেরির সমর্থন ধাপে ধাপে বাড়াচ্ছে। এই পর্ব লেখার সময় বড় প্রজেক্টে সাধারণ header আর find_package-ই মূলধারা; modules-এর দিকে নজর রাখুন, কিন্তু আজকের প্রজেক্ট সেটির ওপর দাঁড় করাবেন না।

১০ · AI-এর যুগে — বানানো package-নাম আর মেশানো Conan

AI-কে “আমার প্রজেক্টে vcpkg দিয়ে JSON লাইব্রেরি যোগ করে দাও” বললে সে আত্মবিশ্বাসের সাথে ফাইল লিখে দেয়। কিন্তু build ফাইল এমন জায়গা, যেখানে একটি অক্ষরের ভুলও configure থামিয়ে দেয় — আর AI-এর ভুলগুলো এখানে খুব নির্দিষ্ট ধরনের:

AI-এর লেখা build ফাইল যাচাইয়ের চেকলিস্ট

• প্রতিটি package-নাম অফিসিয়াল registry-তে আছে (vcpkg.io, conan.io/center), আর বানান হুবহু মেলে
• প্রতিটি version registry-তে সত্যিই আছে; vcpkg-এ baseline আছে, Conan-এ দলের জন্য lockfile
• প্রতিটি CMake target-নাম লাইব্রেরির ডকুমেন্টেশন বা vcpkg-এর usage লেখায় আছে
• Conan 1-এর কোনো চিহ্ন নেই: conans, conanbuildinfo, CONAN_PKG::, [generators] cmake
• একটি খালি build ফোল্ডারে configure, build আর ctest warning ছাড়া চলে — নিজের মেশিনে আর CI-তে
• প্রতিটি নতুন নির্ভরতার লাইসেন্স দেখা হয়েছে, আর সেটা সত্যিই দরকার

শেষ কথা: package-নাম, version আর target-নাম মুখস্থ তথ্য, আর তা প্রায়ই বদলায়। তাই যুক্তি AI-এর কাছ থেকে নিন, তথ্য registry থেকে।