CMake — বড় C++ প্রজেক্ট বিল্ড করার রেসিপি

১ · তিন ফাইল থেকে তিনশো — হাতের কমান্ড কেন আর চলে না

পর্ব ০৩-এ আপনি toolchain-এর পাইপলাইন দেখেছেন: প্রতিটি .cpp ফাইল আলাদা করে compile হয়ে একটি object file হয়, তারপর linker সবগুলো জুড়ে একটি executable বানায়। পর্ব ১১-এ রাকিবের দোকানের প্রজেক্টটি header আর .cpp-তে ভাগ করেছিলেন। তখন কাজ চালাতে একটিমাত্র লাইনই যথেষ্ট ছিল:

g++ -std=c++23 -Wall -Wextra main.cpp money.cpp -o shop

এখন কল্পনা করুন রাকিবের দোকান বড় হয়েছে। এখন তিনটি শাখা, অনলাইন অর্ডার, bKash-এ পেমেন্ট, মাসিক হিসাবের রিপোর্ট। কোডে ৩০০টি .cpp ফাইল, তিনটি বাইরের library, একটি টেস্ট প্রোগ্রাম। দলের কেউ Windows-এ MSVC চালান, কেউ Linux-এ GCC. আর প্রতিটি প্রোগ্রাম দুইভাবে বানাতে হয় — debug করার জন্য একটি, গ্রাহকের জন্য দ্রুতগতির আরেকটি। এখন হাতে কমান্ড লেখার চারটি সমস্যা একসাথে দেখা দেয়:

এর সমাধানের নাম build system. এর মূল ধারণা খুব পুরোনো আর খুব সরল: প্রজেক্টকে একটি dependency graph হিসেবে দেখা। প্রতিটি তৈরি ফাইল কোন কোন ফাইল থেকে আসে — pricing.o আসে pricing.cpp আর সে যে header include করে সেগুলো থেকে; shop আসে সব .o থেকে। Build টুল প্রতিটি তৈরি ফাইলের সময়-চিহ্ন (timestamp) তার উৎসের সাথে মেলায়। উৎস যদি তৈরি ফাইলের চেয়ে নতুন হয়, শুধু তখনই আবার বানায়। বাকি সব আগের মতোই থাকে। এর নাম incremental build.

এই ধারণার প্রথম জনপ্রিয় টুল make (১৯৭৬, Bell Labs). make একটি Makefile পড়ে, যেখানে লেখা থাকে “এই ফাইল বানাতে ওই ফাইলগুলো লাগে, আর এই কমান্ড চালাতে হবে।” C কোর্সে এটি হাতে লিখে দেখেছেন। কিন্তু Makefile হাতে লেখারও সীমা আছে: header-এর নির্ভরতা নিজে মনে রাখতে হয়, Windows-এর MSVC সাধারণ Makefile বোঝে না, আর ৩০০ ফাইলে Makefile নিজেই একটি জটিল প্রোগ্রাম হয়ে যায়। এখানেই CMake-এর জায়গা।

২ · CMake আসলে কী — রেসিপি লেখক, রাঁধুনি নয়

নতুনরা প্রায়ই ভাবেন CMake একটি compiler বা একটি build টুল। দুটোর কোনোটিই নয়। CMake হলো একটি build system generator: আপনি একবার একটি প্ল্যাটফর্ম-নিরপেক্ষ বর্ণনা লেখেন — “এই নামের একটি library আছে, এই ফাইলগুলো নিয়ে; এই প্রোগ্রাম সেটি ব্যবহার করে; C++23 লাগবে।” CMake সেটা পড়ে আপনার মেশিনের জন্য ঠিক build ফাইল লিখে দেয়। তারপর সেই ফাইল দেখে অন্য একটি টুল আসল compile আর link চালায়।

CMake যে ধরনের build ফাইল লেখে, তাকে বলে generator. প্রচলিতগুলো:

ফলে একই CMakeLists.txt দিয়ে রাকিবের দলের Windows-ব্যবহারকারী Visual Studio-তে প্রজেক্ট খোলেন, আর Linux-ব্যবহারকারী terminal-এ Ninja চালান। কেউ কারও build ফাইল হাতে লেখেন না। আজকের IDE-গুলো — Visual Studio, CLion, VS Code-এর CMake Tools, Qt Creator — সরাসরি CMakeLists.txt বোঝে। এজন্যই CMake C++ জগতে প্রায় মানদণ্ড হয়ে গেছে, যদিও standard-এ এর কোনো উল্লেখ নেই।

খেয়াল করুন, CMake একমাত্র পথ নয়। Google-এর Bazel, Meson, xmake, build2 — সবই C++ build করে, আর কিছু ক্ষেত্রে CMake-এর চেয়ে ভালোও। কিন্তু বাইরের বেশিরভাগ C++ library CMake দিয়ে আসে, আর চাকরির বিজ্ঞাপনে “CMake” শব্দটি সবচেয়ে বেশি দেখা যায়। তাই এই কোর্সে CMake.

৩ · প্রথম CMakeLists.txt — চার লাইনের রেসিপি

CMake-এর রেসিপি থাকে প্রজেক্টের মূল ফোল্ডারে, CMakeLists.txt নামের একটি ফাইলে (নামের বানান হুবহু এমন)। পর্ব ১১-এর তিন ফাইলের দোকানের প্রজেক্টের জন্য এর সবচেয়ে ছোট রূপ:

cmake_minimum_required(VERSION 3.25)
project(shop VERSION 1.0 LANGUAGES CXX)

add_executable(shop main.cpp money.cpp)
target_compile_features(shop PRIVATE cxx_std_23)

অনেক টিউটোরিয়ালে লাইন ৫-এর বদলে পুরো প্রজেক্টের জন্য একটি variable দেখবেন:

set(CMAKE_CXX_STANDARD 23)           # সব target-এর ডিফল্ট standard
set(CMAKE_CXX_STANDARD_REQUIRED ON)  # না পেলে থামবে, পুরোনোতে নামবে না
set(CMAKE_CXX_EXTENSIONS OFF)        # gnu++23 নয়, খাঁটি -std=c++23

দুটোই চলে। একটি ছোট অ্যাপের জন্য এই তিন লাইন সুবিধাজনক। কিন্তু library বানালে target_compile_features(... PUBLIC cxx_std_23) ভালো, কারণ এটা ব্যবহারকারীদেরও জানিয়ে দেয় “আমার header বুঝতে C++23 লাগবে” — অংশ ৫-এ এর মানে পরিষ্কার হবে। CMAKE_CXX_EXTENSIONS OFF রাখলে GCC-র নিজস্ব extension বন্ধ থাকে, ফলে কোড অন্য compiler-এ নিয়ে গেলে কম চমক আসে।

তিন ধাপ: configure, generate, build

রেসিপি লেখা হলো। এবার প্রজেক্টের মূল ফোল্ডারে terminal খুলে দুটি কমান্ড:

cmake -S . -B build -G Ninja    # source: এই ফোল্ডার, build: build/ ফোল্ডার
cmake --build build             # compile + link (ভেতরে Ninja চালায়)
./build/shop                    # Windows-এ: build\shop.exe

প্রথম কমান্ডটি আসলে দুটি কাজ করে — configure আর generate. দ্বিতীয়টি build. -G Ninja না দিলে CMake নিজের ডিফল্ট generator নেয় (Linux-এ সাধারণত Makefile, Windows-এ Visual Studio). নিচের ডায়াগ্রামে দেখুন প্রতিটি ধাপে build/ ফোল্ডারে কী কী ফাইল জন্ম নেয়:

shop/
├── CMakeLists.txt
├── main.cpp
├── money.h
└── money.cpp          # build/ এখনো নেই

-- The CXX compiler identification is GNU 14.2.0
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Configuring done
build/
├── CMakeCache.txt     # মনে রাখা সিদ্ধান্ত
└── CMakeFiles/        # compiler পরীক্ষার ফল

-- Generating done
-- Build files have been written to: /home/rakib/shop/build
build/
├── CMakeCache.txt
├── CMakeFiles/
├── build.ninja        # Ninja-র জন্য কাজের তালিকা
└── cmake_install.cmake

[1/3] Building CXX object CMakeFiles/shop.dir/main.cpp.o
[2/3] Building CXX object CMakeFiles/shop.dir/money.cpp.o
[3/3] Linking CXX executable shop
build/
├── CMakeFiles/shop.dir/main.cpp.o, money.cpp.o
└── shop               # Windows-এ shop.exe

shop/
├── CMakeLists.txt
├── main.cpp
├── money.h
└── money.cpp          # একটুও বদলায়নি
# আবার শুরু: cmake -S . -B build
# চাইলে পাশাপাশি: build-debug/ আর build-release/

৪ · কোনটি আবার build হবে — dependency graph-এর হিসাব

অংশ ১-এর দ্বিতীয় সমস্যা ছিল “একটি লাইন বদলালে সব আবার compile.” এখন দেখা যাক Ninja আর Make এটি কীভাবে এড়ায়। এজন্য দুটি তথ্য লাগে। প্রথমটি CMake দেয়: কোন .o কোন .cpp থেকে, কোন library কোন .o থেকে, কোন প্রোগ্রাম কোন library থেকে। দ্বিতীয়টি compiler দেয়: প্রতিটি .cpp compile করার সময় সে একটি ছোট তালিকা লিখে রাখে, ওই ফাইল কোন কোন header পড়েছে (GCC-তে -MD flag, যা CMake নিজেই বসায়)। দুটো মিলিয়ে build টুল পুরো graph জানে।

এবার দোকানের প্রজেক্টটি একটু বড় রূপে ভাবুন: inventory.cpp আর pricing.cpp মিলে একটি library, আর main.cpp সেই library ব্যবহার করে একটি প্রোগ্রাম। pricing.h header-টি pricing.cpp আর main.cpp দুটোই include করে, inventory.cpp করে না। নিচে পাঁচটি ঘটনায় দেখুন কী কী আবার তৈরি হয় (লাল দাগ = এই build-এ আবার বানানো হলো):

[1/5] Building CXX object CMakeFiles/shop_core.dir/src/inventory.cpp.o
[2/5] Building CXX object CMakeFiles/shop_core.dir/src/pricing.cpp.o
[3/5] Building CXX object CMakeFiles/shop_cli.dir/apps/main.cpp.o
[4/5] Linking CXX static library libshop_core.a
[5/5] Linking CXX executable shop_cli

ninja: no work to do.

[1/3] Building CXX object CMakeFiles/shop_core.dir/src/pricing.cpp.o
[2/3] Linking CXX static library libshop_core.a
[3/3] Linking CXX executable shop_cli
# inventory.cpp আর main.cpp ছোঁয়াই হয়নি

[1/4] Building CXX object CMakeFiles/shop_core.dir/src/pricing.cpp.o
[2/4] Building CXX object CMakeFiles/shop_cli.dir/apps/main.cpp.o
[3/4] Linking CXX static library libshop_core.a
[4/4] Linking CXX executable shop_cli

[0/1] Re-running CMake...
-- Configuring done
-- Generating done
[1/5] Building CXX object ...inventory.cpp.o
# ...flag বদলেছে, তাই যাদের কমান্ড বদলেছে সবাই আবার

“কোনটি আবার বানাতে হবে” প্রশ্নটি দেখতে সহজ, কিন্তু এখানেই সবচেয়ে বিরক্তিকর build-বাগ লুকিয়ে থাকে: নির্ভরতা ভুল জানালে টুল এমন ফাইল আবার বানায় না যেটা বানানো দরকার ছিল। তখন পুরোনো .o নতুন header-এর সাথে link হয়, আর অদ্ভুত crash আসে যা “clean build”-এ উধাও। CMake আর compiler-এর স্বয়ংক্রিয় header-তালিকা এই ঝুঁকি প্রায় শূন্যে নামিয়ে আনে — যদি আপনি হাতের কৌশলে সেটা না ভাঙেন (অংশ ৯)।

৫ · Modern CMake — target আর তার property

CMake ২০০০ সাল থেকে আছে, আর তার লেখার ধাঁচ সময়ের সাথে অনেক বদলেছে। পুরোনো ধাঁচে সবকিছু ছিল global variable আর global কমান্ড: “সবার জন্য এই include ফোল্ডার, সবার জন্য এই flag.” প্রায় ২০১৪ সালের CMake ৩.০ থেকে যে ধাঁচ চালু হয়েছে, তাকে বলে modern CMake. এর মূল কথা একটি: সবকিছু একটি target-এর গায়ে লেখা। Target মানে CMake যা বানায় — একটি প্রোগ্রাম বা একটি library. প্রতিটি target-এর নিজের property থাকে: কোন source, কোন include ফোল্ডার, কোন flag, কোন library-র সাথে link.

তিন রকম library

add_library(shop_core STATIC src/inventory.cpp src/pricing.cpp)
add_library(shop_report SHARED src/report.cpp)
add_library(shop_money INTERFACE)       # শুধু header, কোনো .cpp নেই

add_library-এ ধরন না লিখলে CMake BUILD_SHARED_LIBS নামের একটি variable দেখে ঠিক করে — ব্যবহারকারী configure-এর সময় -DBUILD_SHARED_LIBS=ON দিয়ে বদলাতে পারেন। শেখার সময় STATIC লিখে দেওয়াই সবচেয়ে সহজ।

PUBLIC, PRIVATE, INTERFACE — “শুধু আমার” আর “আমার ব্যবহারকারীরও”

এবার modern CMake-এর সবচেয়ে গুরুত্বপূর্ণ ধারণা। প্রতিটি target_* কমান্ডে একটি শব্দ বসে, যা বলে এই জিনিসটি কার লাগবে:

target_include_directories(shop_core PUBLIC include)
target_link_libraries(shop_core
    PUBLIC  shop_money    # shop_core-এর header shop_money-র header পড়ে
    PRIVATE fmt::fmt)     # fmt শুধু shop_core-এর .cpp-র ভেতরে
target_link_libraries(shop_cli PRIVATE shop_core)

যে জিনিসগুলো এভাবে ব্যবহারকারীর দিকে ছড়ায় — include ফোল্ডার, compile flag, C++ standard, link করার library — CMake-এর ভাষায় সেগুলো usage requirements. আর A যদি B-কে PUBLIC-ভাবে ব্যবহার করে, B যদি C-কে PUBLIC-ভাবে, তাহলে A-র ব্যবহারকারীও C পায় — এর নাম transitive dependency. সিদ্ধান্তের সহজ নিয়ম:

• B-এর কোনো header যদি আপনার public header-এ #include হয়, বা আপনার public ফাংশনের টাইপে B আসে → PUBLIC.
• B শুধু আপনার .cpp ফাইলের ভেতরে ব্যবহার হয় → PRIVATE.
• আপনার নিজের কিছু compile হয় না, শুধু ব্যবহারকারীর লাগে (header-only) → INTERFACE.

add_library(shop_money INTERFACE)
target_include_directories(shop_money INTERFACE money/include)
target_compile_features(shop_money INTERFACE cxx_std_23)
# ব্যবহারকারী পাবে: -I money/include, C++23

-I include              # নিজের PUBLIC
-I money/include        # shop_money থেকে
-I .../fmt/include      # fmt (PRIVATE, তবু নিজে পায়)
-std=gnu++23
ব্যবহারকারীকে দেবে: include, money/include, C++23
দেবে না: fmt-এর include

compile:  -I include  -I money/include  -std=gnu++23
          # fmt-এর include নেই — দরকারও নেই
link:     libshop_core.a  libfmt.a
          # static library-র PRIVATE নির্ভরতাও link-এ লাগে,
          # CMake নিজেই যোগ করে

apps/main.cpp:1:
include/shop/pricing.h:3:10: fatal error: fmt/format.h:
    No such file or directory
# সমাধান ১: target_link_libraries(shop_core PUBLIC fmt::fmt)
# সমাধান ২ (ভালো): header থেকে fmt সরিয়ে .cpp-তে নিন

উল্টো ভুলটিও ঘটে: সবকিছু PUBLIC করে দেওয়া। তখন প্রতিটি ব্যবহারকারী অদরকারি include ফোল্ডার আর flag পায়, compile ধীর হয়, আর library-র ভেতরের একটি বদল পুরো প্রজেক্টে ছড়িয়ে পড়ে। PRIVATE হলো ডিফল্ট মনোভাব — দরকার প্রমাণ হলে তবেই PUBLIC.

৬ · দোকানের প্রজেক্ট সাজানো — src/, include/, apps/, tests/

এবার সব একসাথে। রাকিবের দোকানের প্রজেক্টের একটি বাস্তবসম্মত বিন্যাস — বেশিরভাগ খোলা C++ প্রজেক্ট মোটামুটি এই ধাঁচ মানে:

shop/
├── CMakeLists.txt          # মূল রেসিপি
├── CMakePresets.json       # প্রচলিত build-এর নাম (অংশ ৭)
├── include/shop/           # public header — ব্যবহারকারী যা দেখবে
│   ├── inventory.h
│   └── pricing.h
├── src/                    # library-র .cpp — ভেতরের কাজ
│   ├── inventory.cpp
│   └── pricing.cpp
├── apps/
│   └── main.cpp            # shop_cli প্রোগ্রাম
└── tests/
    └── pricing_test.cpp    # টেস্ট

এই বিন্যাসের পেছনের যুক্তি: আসল কাজ থাকে library-তে (shop_core), প্রোগ্রাম (shop_cli) শুধু একটি পাতলা খোলস যা ব্যবহারকারীর সাথে কথা বলে। ফলে একই library টেস্ট প্রোগ্রামও ব্যবহার করতে পারে, পরে একটি GUI বা ওয়েব সার্ভারও। include/shop/-এর ভেতরে আরেকটি shop ফোল্ডার কেন? যাতে ব্যবহারকারী লেখেন #include "shop/pricing.h" — অন্য কোনো library-র pricing.h-এর সাথে নাম মিলে যাওয়ার ভয় থাকে না। ফাইলগুলো দেখুন:

cmake_minimum_required(VERSION 3.25)
project(shop VERSION 1.0 LANGUAGES CXX)

# ---- library: আসল কাজ ----
add_library(shop_core STATIC
    src/inventory.cpp
    src/pricing.cpp)
add_library(shop::core ALIAS shop_core)
target_include_directories(shop_core PUBLIC include)
target_compile_features(shop_core PUBLIC cxx_std_23)

# ---- প্রোগ্রাম: পাতলা খোলস ----
add_executable(shop_cli apps/main.cpp)
target_link_libraries(shop_cli PRIVATE shop::core)

# ---- টেস্ট ----
enable_testing()
add_executable(shop_tests tests/pricing_test.cpp)
target_link_libraries(shop_tests PRIVATE shop::core)
add_test(NAME pricing COMMAND shop_tests)

#pragma once

namespace shop::pricing {
    inline constexpr long vat_percent = 15;

    long with_vat(long paisa);                  // ঘোষণা
    long apply_discount(long paisa, int pct);   // ঘোষণা
}

#include "shop/pricing.h"

namespace shop::pricing {
    long with_vat(long paisa) {
        return paisa + paisa * vat_percent / 100;
    }
    long apply_discount(long paisa, int pct) {
        return paisa - paisa * pct / 100;
    }
}

#include "shop/pricing.h"
#include <print>

int main() {
    long bill = shop::pricing::with_vat(65000);
    std::println("Bill: {}.{:02} Tk", bill / 100, bill % 100);
}

লক্ষ করুন CMakeLists.txt-এ কোথাও -I, -std= বা -l নেই। আছে শুধু কী বানাতে হবে আর কে কাকে ব্যবহার করে। এই প্রজেক্ট ৫০০ ফাইলে বড় হলে সাধারণত প্রতিটি ফোল্ডারে আলাদা একটি CMakeLists.txt রাখা হয়, আর মূল ফাইল সেগুলোকে add_subdirectory দিয়ে ডেকে আনে — add_subdirectory(src), add_subdirectory(apps). প্রতিটি দলের রেসিপি তার নিজের ফোল্ডারে থাকে।

পাতার রানার একবারে একটিই ফাইল চালাতে পারে, তাই নিচে library আর প্রোগ্রামের কাজটুকু এক ফাইলে রাখা হলো। বাস্তবে namespace shop::pricing অংশটি থাকত shop_core-এ, আর main থাকত shop_cli-তে:

#include <print>
#include <string>
#include <vector>

namespace shop::pricing {               // real project: shop_core library
    long with_vat(long paisa) { return paisa + paisa * 15 / 100; }
}

struct Item { std::string name; long paisa; int qty; };

int main() {                            // real project: shop_cli program
    std::vector<Item> cart{{"Rice", 8000, 5}, {"Tea", 25000, 1}};
    long total = 0;
    for (const auto& it : cart) total += it.paisa * it.qty;
    std::println("Items: {}", cart.size());
    std::println("Subtotal: {}.{:02} Tk", total / 100, total % 100);
    long bill = shop::pricing::with_vat(total);
    std::println("With VAT: {}.{:02} Tk", bill / 100, bill % 100);
}

৭ · Build type, warning, sanitizer আর presets

অংশ ১-এর চতুর্থ সমস্যা ছিল Debug আর Release. CMake-এ এর নাম build type, আর চারটি তৈরি আছে:

কোথায় বাছবেন তা generator-এর ওপর নির্ভর করে। Ninja আর Makefile হলো single-config generator — একটি build ফোল্ডারে একটিই ধরন, configure-এর সময় বলে দিতে হয়: cmake -S . -B build-rel -DCMAKE_BUILD_TYPE=Release. কিছু না বললে কোনো optimization বা debug flag ছাড়াই build হয়, যা প্রায়ই কারও কাম্য নয়। Visual Studio আর Xcode হলো multi-config — একই ফোল্ডারে সব ধরন থাকে, build-এর সময় বাছতে হয়: cmake --build build --config Release.

Release-এর -DNDEBUG লক্ষ করুন। NDEBUG সংজ্ঞায়িত থাকলে <cassert>-এর assert পুরো মুছে যায়। নিচের প্রোগ্রামটি নিজেই বলে দেয় সে কোন ধাঁচে build হয়েছে:

#include <cassert>
#include <print>

int stock_after_sale(int stock, int sold) {
    assert(sold <= stock && "cannot sell more than stock");
    return stock - sold;
}

int main() {
#ifdef NDEBUG
    std::println("Release-style build: NDEBUG defined, assert is OFF");
#else
    std::println("Debug-style build: NDEBUG not defined, assert is ON");
#endif
    std::println("__cplusplus = {}", __cplusplus);
    std::println("Stock left: {}", stock_after_sale(10, 3));
}

Warning — প্রতিটি target-এ, compiler বুঝে

পর্ব ০৩ থেকে আপনি -Wall -Wextra ছাড়া compile করেন না। CMake-এ এটি target-এর property, আর GCC/Clang আর MSVC-র flag আলাদা বলে একটি সরল শর্ত লাগে:

if(MSVC)
    target_compile_options(shop_core PRIVATE /W4 /permissive-)
else()
    target_compile_options(shop_core PRIVATE -Wall -Wextra -Wpedantic)
endif()

এখানে PRIVATE কেন? কারণ আপনার warning-এর পছন্দ আপনার নিজের কোডের জন্য; ব্যবহারকারীর ঘাড়ে চাপানো উচিত নয়। একই কাজ এক লাইনে করা যায় generator expression দিয়ে — $<...> আকারের ছোট শর্ত, যা configure-এর সময় নয়, build ফাইল লেখার সময় মূল্যায়ন হয়। যেমন "$<$<CONFIG:Debug>:-Og>" মানে “শুধু Debug build-এ -Og.” পড়তে কঠিন বলে শুরুতে if() ভালো; অন্যদের CMake ফাইলে এগুলো দেখলে অন্তত চিনতে পারবেন।

Sanitizer — একটি চালু-বন্ধের সুইচ

পর্ব ৪৩-এ দেখেছেন, টেস্ট চালানোর সময় AddressSanitizer আর UBSan কত ভুল ধরে। CMake-এ এগুলোকে একটি option-এর পেছনে রাখুন, যাতে দরকারমতো চালু করা যায়:

option(SHOP_SANITIZE "Build with ASan and UBSan" OFF)
if(SHOP_SANITIZE AND NOT MSVC)
    target_compile_options(shop_core PUBLIC -fsanitize=address,undefined
                                            -fno-omit-frame-pointer)
    target_link_options(shop_core PUBLIC -fsanitize=address,undefined)
endif()

এবার PUBLIC — কারণ sanitizer-এর runtime প্রোগ্রাম আর টেস্ট দুটোর link-এও লাগে, আর তাদের নিজের কোডও যাচাই হওয়া উচিত। চালু করতে: cmake -S . -B build-asan -DSHOP_SANITIZE=ON.

CMakePresets.json — লম্বা কমান্ডের বদলে একটি নাম

এতক্ষণে configure-কমান্ড লম্বা হয়ে গেছে: generator, build type, sanitizer… দলের সবাই যাতে একই কমান্ড ব্যবহার করেন, CMake ৩.১৯ থেকে CMakePresets.json ফাইল আছে। এটি Git-এ থাকে, আর IDE-গুলোও পড়ে:

{
  "version": 6,
  "configurePresets": [
    { "name": "debug", "generator": "Ninja",
      "binaryDir": "build/debug",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug",
                          "SHOP_SANITIZE": "ON",
                          "CMAKE_EXPORT_COMPILE_COMMANDS": "ON" } },
    { "name": "release", "generator": "Ninja",
      "binaryDir": "build/release",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Release" } }
  ]
}

cmake --preset debug          # configure, সব সেটিং ফাইল থেকে
cmake --build build/debug     # build

ব্যক্তিগত সেটিং (নিজের compiler-এর ঠিকানা ইত্যাদি) রাখার জন্য আছে CMakeUserPresets.json, যা Git-এ যায় না। “version” সংখ্যাটি ফাইলের ধরনের version — নতুন সংখ্যা মানে নতুন CMake লাগবে; আপনার দলের সবার CMake যেটা বোঝে, সেটাই দিন।

compile_commands.json — IDE আর টুলের জন্য মানচিত্র

উপরের preset-এ CMAKE_EXPORT_COMPILE_COMMANDS চালু আছে। এতে CMake build ফোল্ডারে compile_commands.json নামের একটি ফাইল লেখে: প্রতিটি .cpp-এর জন্য ঠিক কোন কমান্ড, কোন include ফোল্ডার, কোন flag. VS Code-এর clangd, clang-tidy আর অনেক টুল এই ফাইল পড়েই আপনার কোড বোঝে — এটি ছাড়া এডিটরে “shop/pricing.h not found”-এর লাল দাগ দেখা যায়, যদিও build ঠিকই চলে। এটি Ninja আর Makefile generator-এ কাজ করে; Visual Studio generator-এ নয়।

৮ · বাইরের library — find_package, FetchContent আর package manager

বাস্তব প্রজেক্ট সব কিছু নিজে লেখে না। টাকা সুন্দর করে ছাপাতে fmt, JSON পড়তে একটি JSON library, টেস্টের জন্য GoogleTest. প্রশ্ন হলো, এগুলো আপনার মেশিনে আসবে কীভাবে, আর CMake কীভাবে জানবে কোথায় আছে। তিনটি পথ:

পথ ১ — find_package: আগে থেকে বসানো library খোঁজা

find_package(fmt CONFIG REQUIRED)      # না পেলে configure থামবে
find_package(Threads REQUIRED)          # পর্ব ৪৫-এর thread-এর জন্য
target_link_libraries(shop_core PRIVATE fmt::fmt Threads::Threads)

find_package মেশিনে বসানো library খোঁজে — Linux-এ apt install libfmt-dev দিয়ে বসানো, বা কোনো package manager-এর ফোল্ডারে। পেলে সে একটি imported target দেয়, যেমন fmt::fmt, যার ভেতরে include ফোল্ডার, library ফাইল আর দরকারি flag সব আগে থেকে ভরা। আপনি শুধু link করেন। পুরোনো ধাঁচে মানুষ ${FMT_INCLUDE_DIRS} আর ${FMT_LIBRARIES}-এর মতো variable হাতে বসাত; imported target সেই ঝামেলা দূর করেছে।

পথ ২ — FetchContent: build-এর সময় নামিয়ে আনা

মেশিনে বসানো না থাকলে? CMake নিজেই source নামিয়ে আপনার প্রজেক্টের অংশ হিসেবে build করতে পারে — FetchContent দিয়ে। টেস্টের জন্য GoogleTest-এর উদাহরণ:

include(FetchContent)
FetchContent_Declare(googletest
    GIT_REPOSITORY https://github.com/google/googletest.git
    GIT_TAG        v1.15.2)            # নির্দিষ্ট version — কখনো "main" নয়
FetchContent_MakeAvailable(googletest)

add_executable(shop_tests tests/pricing_test.cpp)
target_link_libraries(shop_tests PRIVATE shop::core GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(shop_tests)

# এখনো কিছু নামেনি — শুধু CMake মনে রাখল:
# "googletest" নামের জিনিস এই ঠিকানায়, এই tag-এ
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG        v1.15.2

build/_deps/
├── googletest-src/     # নামানো source
├── googletest-build/   # তার নিজের build
└── googletest-subbuild/
# পরের configure-এ আবার নামায় না

# googletest-src/CMakeLists.txt আপনার প্রজেক্টের অংশ হয়ে চলে
নতুন target:  GTest::gtest  GTest::gtest_main
              GTest::gmock  GTest::gmock_main
# প্রতিটির include, flag — usage requirements-সহ

    Start 1: Pricing.AddsVat
1/2 Test #1: Pricing.AddsVat ..........   Passed
    Start 2: Pricing.Discount
2/2 Test #2: Pricing.Discount .........   Passed
100% tests passed, 0 tests failed out of 2

FetchContent সুবিধাজনক, কিন্তু খরচও আছে: প্রতিটি নতুন build ফোল্ডারে আবার নামানো আর পুরো library compile করা, আর অফিসের ইন্টারনেট বন্ধ থাকলে configure-ই হয় না। ছোট বা টেস্টের library-র জন্য এটা দারুণ; বড়, ভারী library-র জন্য পরের পথটি ভালো।

পথ ৩ — package manager: vcpkg আর Conan

C++-এর কোনো “অফিসিয়াল” package manager নেই (কেন নেই — ভাবনার প্রশ্ন ০৩)। সবচেয়ে প্রচলিত দুটি: Microsoft-এর vcpkg আর JFrog-সমর্থিত Conan. দুটোই একই কাজ করে: library-গুলো আপনার compiler আর প্ল্যাটফর্মের জন্য build করে (বা আগে build করা কপি নামিয়ে) একটি ফোল্ডারে রাখে, আর CMake-কে জানায় সেখানে খুঁজতে। ফলে আপনার CMakeLists.txt-এ থাকে শুধু সাধারণ find_package(fmt CONFIG REQUIRED) — library কোথা থেকে এল, রেসিপি তা জানেই না। vcpkg-তে প্রজেক্টের মূল ফোল্ডারে একটি vcpkg.json ফাইলে তালিকা থাকে:

{
  "name": "shop",
  "dependencies": [ "fmt", "gtest" ]
}

তারপর configure-এর সময় vcpkg-এর একটি toolchain file দিয়ে দিতে হয় (সাধারণত preset-এর toolchainFile-এ, বা -DCMAKE_TOOLCHAIN_FILE=... দিয়ে), যা vcpkg/scripts/buildsystems/vcpkg.cmake-এ থাকে। বাকি সব আগের মতোই।

৯ · টেস্টের এক ঝলক আর সাধারণ ভুলগুলো

অংশ ৬-এর CMakeLists.txt-এ তিনটি লাইন দেখেছেন: enable_testing(), একটি টেস্ট-প্রোগ্রাম, আর add_test. এর মানে, CMake আপনার প্রজেক্টের টেস্টের একটি তালিকা রাখে, আর ctest নামের সহকারী টুল সেই তালিকা চালায়। কোনো টেস্ট-প্রোগ্রাম ০ ফেরত দিলে পাস, অন্য কিছু দিলে ফেল — খুব সরল চুক্তি।

cmake --build build
ctest --test-dir build --output-on-failure    # ফেল হলে প্রোগ্রামের আউটপুট দেখাও
ctest --test-dir build -R pricing              # নামে "pricing" আছে শুধু সেগুলো

বড় প্রজেক্টে প্রতিটি পরিবর্তনের পর এই দুই কমান্ড একটি সার্ভারে নিজে নিজে চলে — এর নাম continuous integration. Unit test কীভাবে লিখবেন, GoogleTest-এর EXPECT_EQ, debugger আর CI — সব পর্ব ৪৮-এ। এখানে শুধু মনে রাখুন: টেস্ট হলো আরেকটি target, যা আপনার library-কে link করে — ঠিক যেমন shop_cli. এজন্যই অংশ ৬-এ কাজ library-তে রাখা হয়েছিল।

যে ভুলগুলো সবচেয়ে বেশি দেখা যায়

file(GLOB) নিয়ে একটু বেশি বলা দরকার, কারণ এটা দেখতে খুব সুবিধাজনক। এটি configure-এর মুহূর্তে ফোল্ডারে যা আছে তার একটি তালিকা বানায়। পরে আপনি নতুন report.cpp যোগ করলেন — CMakeLists.txt বদলায়নি, তাই Ninja CMake-কে আবার চালায় না, নতুন ফাইলটি build-এ ঢোকে না, আর আপনি পান রহস্যময় linker error. CMake-এর নিজের ডকুমেন্টেশনই source জোগাড়ে GLOB ব্যবহার করতে নিরুৎসাহিত করে। CONFIGURE_DEPENDS নামের একটি বিকল্প আছে যা প্রতি build-এ ফোল্ডার আবার দেখে, তবে সেটা সব generator-এ নির্ভরযোগ্য নয় আর build ধীর করে। হাতে লেখা তালিকা একটু খাটুনির, কিন্তু Git-এর ইতিহাসে স্পষ্ট দেখা যায় কোন ফাইল কবে যোগ হলো।

১০ · AI-এর যুগে — AI-এর লেখা CMake যাচাই

AI-কে “আমার প্রজেক্টের CMakeLists.txt লিখে দাও” বললে সে কয়েক সেকেন্ডে একটি ফাইল দেয়, আর প্রায়ই সেটা চলেও। সমস্যা অন্য জায়গায়: ইন্টারনেটে CMake-এর লেখার বড় অংশ ২০১০-এর দশকের শুরুর, পুরোনো ধাঁচের। AI সেখান থেকেই শিখেছে। তাই তার CMake প্রায়ই “আজ চলে, কাল বড় হলে ভাঙে” ধরনের। যে ভুলগুলো বারবার দেখা যায়:

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

• cmake_minimum_required-এর সংখ্যা বাস্তব, আর আমার CMake (cmake --version) সেটি সমর্থন করে
• কোনো global include_directories, link_libraries, add_definitions বা CMAKE_CXX_FLAGS নেই
• প্রতিটি PUBLIC-এর পেছনে কারণ আছে: নির্ভরতাটি আমার public header-এ আসে
• নতুন একটি খালি build ফোল্ডারে cmake -S . -B build আর cmake --build build warning ছাড়া চলে
• যে target-নাম link হচ্ছে (fmt::fmt, GTest::gtest_main) সেটা library-র ডকুমেন্টেশনে আছে
• বাইরের library-র version নির্দিষ্ট করা — tag, commit বা vcpkg-এর version
• ctest --test-dir build সব টেস্ট খুঁজে পায় আর চালায়

শেষ কথা: CMake ফাইলও কোড। এটি Git-এ থাকে, রিভিউ হয়, আর এর বাগ প্রজেক্টের সবাইকে ভোগায়। AI-এর দেওয়া CMake প্রথম খসড়া হিসেবে দারুণ — তার প্রতিটি target_link_libraries-এর শব্দটি যে আপনি নিজে বুঝে রেখেছেন, সেটাই আপনাকে আলাদা করবে।