Package Management dengan Conan

vcpkg pada Chapter lalu tumbuh dari ekosistem Microsoft dan paling mulus ketika proyek berbasis CMake. Pesaing terbesarnya mengambil sudut pandang berbeda: Conan — manajer paket open source yang ditulis dengan Python — tidak bertanya “build system apa yang kamu pakai”, melainkan “seperti apa mesin yang akan membangun proyekmu”. Jawabannya disimpan dalam profil, dan dari profil itu Conan menyediakan paket biner yang sudah jadi: library tidak perlu dikompilasi ulang di mesin Anda bila konfigurasinya sudah pernah dibangun seseorang. Pada Chapter ini kita ikuti alur Conan dari profile sampai preset CMake, lalu menyandingkannya dengan vcpkg dalam satu tabel.

Conan dalam Satu Pandangan #

Tiga konsep menopang Conan 2 (versi yang dibahas di sini):

• Recipe: resep sebuah paket — file conanfile.py milik tiap library yang mendeskripsikan sumber, opsi, dan cara membangunnya. Resep-respe tersimpan di remote publik ConanCenter .
• Paket biner: satu recipe menghasilkan banyak biner — satu untuk tiap kombinasi compiler, versi, arsitektur, dan build type. Conan mengunduh biner yang cocok dengan mesin Anda; bila tidak ada, ia membangunnya sekali lalu menyimpannya di cache lokal (~/.conan2).
• Profil: gambaran mesin build — OS, arsitektur, compiler beserta versinya, build type — yang menentukan biner mana yang kompatibel.

Profil: Menggambarkan Mesin Build #

Perintah pertama setelah memasang Conan (misalnya lewat pip install conan) biasanya membuat profil default secara otomatis:

conan profile detect

Hasilnya adalah file profil yang membaca mesin Anda — GCC 14.2 pada sistem Linux 64-bit akan menghasilkan isi semacam ini:

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

Profil inilah alasan biner Conan bisa dibagikan dengan aman: paket yang dibangun untuk GCC 14 tidak akan dikirim ke mesin ber-Clang, karena keduanya punya profil berbeda. Profil juga tempat menyunting kebutuhan khusus — menaikkan build_type=Debug, mengganti compiler.libcxx, atau menambah flag kustom lewat bagian [conf].

Mendeklarasikan Dependensi #

Cara paling ringkas mendeklarasikan kebutuhan proyek adalah conanfile.txt di folder teratas:

[requires]
zlib/1.3.1

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

Bagian [requires] memuat daftar paket beserta versinya — zlib/1.3.1 berarti “zlib, versi 1.3.1”. Bagian [generators] memilih apa yang dibuat Conan saat instalasi: CMakeToolchain menulis file toolchain, dan CMakeDeps menulis file konfigurasi paket sehingga find_package menemukannya — pasangan yang mengingatkan kita pada jalur find_package di Chapter CMake Dependencies. [layout] menentukan struktur folder build.

Bila kebutuhannya lebih dari sekadar menarik paket — misalnya proyek kita sendiri akan di-package untuk orang lain — deklarasi naik kelas menjadi conanfile.py: satu file Python dengan fungsi build(), package(), dan requirements() yang bisa berisi logika apa pun. Untuk aplikasi biasa, conanfile.txt sudah cukup.

conan install dan Integrasi CMake #

Dua perintah menuntaskan persiapan:

conan install .
cmake --preset conan-release
cmake --build --preset conan-release

conan install . membaca conanfile.txt, memeriksa profil, lalu mengunduh biner zlib yang cocok — atau membangunnya bila belum ada. Setelah itu Conan menulis conan_toolchain.cmake beserta CMakePresets.json, sehingga dua perintah cmake --preset ... berikutnya memakai toolchain itu tanpa flag -DCMAKE_TOOLCHAIN_FILE yang diketik manual seperti pada Chapter vcpkg. Di dalam CMakeLists.txt, dependensinya diambil dengan cara yang sudah kita kenal:

cmake_minimum_required(VERSION 3.20)
project(Checksum LANGUAGES CXX)

find_package(ZLIB REQUIRED)

add_executable(checksum fnv1a.cpp)
target_link_libraries(checksum PRIVATE ZLIB::ZLIB)

Perhatikan bahwa find_package(ZLIB REQUIRED) memakai mode module — CMake membawa modul FindZLIB bawaan — dan tetap bekerja karena CMakeDeps menyediakan variabel dan target yang dicarinya. Target ZLIB::ZLIB membawa include dan file library sekaligus, persis pola imported target pada Chapter sebelumnya.

Aplikasi Kita: Checksum #

Program yang dideklarasikan di atas menghitung checksum teks. Versi yang kami uji di lingkungan praktikum ini memakai algoritma FNV-1a — murni C++, tanpa library luar:

#include <cstdint>
#include <iostream>
#include <string>
#include <vector>

// Checksum FNV-1a 32-bit — versi tanpa library eksternal apa pun.
std::uint32_t fnv1a(const std::string& teks) {
    std::uint32_t hash = 2166136261u;
    for (unsigned char c : teks) {
        hash ^= c;
        hash *= 16777619u;
    }
    return hash;
}

int main() {
    std::vector<std::string> kata {"hello", "conan", "C++23"};
    std::cout << std::hex;
    for (const std::string& s : kata) {
        std::cout << s << " -> " << fnv1a(s) << "\n";
    }
    return 0;
}

Output yang Dihasilkan:

hello -> 4f9f2cab
conan -> 702d4f50
C++23 -> dead98ef

Versi yang me-link ke zlib dari Conan mengganti algoritmanya dengan crc32 — pustaka klasik yang tersedia lewat paket zlib/1.3.1 tadi:

#include <zlib.h>

unsigned long crc = crc32(0L, Z_NULL, 0);
crc = crc32(crc, reinterpret_cast<const Bytef*>(s.data()),
            static_cast<uInt>(s.size()));
std::cout << s << " -> " << std::hex << crc << "\n";

Perbandingan keduanya memperlihatkan pola yang sama dengan chapter vcpkg: source aplikasi hanya menyentuh header library, dan urusan mendapatkan header-plus-library diserahkan sepenuhnya ke manajer paket.

vcpkg atau Conan #

Tabel itu berakhir damai: keduanya alat yang matang, dan pilihan biasanya jatuh ke kebiasaan tim serta build system yang dipakai. Yang jauh lebih penting adalah keputusan yang lebih tinggi di atasnya — layakkah sebuah library menjadi dependensi kita, dan strategi apa yang mengelola semuanya. Itulah topik chapter berikutnya.

Referensi: Dokumentasi Conan 2 , conanfile.txt .