Selama section ini kita merakit hampir semua mesin build C++: modul yang dipecah ke header dan source, simbol yang disambung linker, library yang dikemas dengan ar, Makefile dan CMake yang mengotomatiskan semuanya, dependensi yang ditarik lewat manajer paket, tes yang dilari CTest, sampai konfigurasi Debug dan Release. Semua bagian itu akhirnya butuh satu rumah bersama — struktur folder proyek. Layout yang konsisten bukan sekadar kerapian: compiler mencari header, CMake menyusun target, dan developer baru menaksir isi proyek, semuanya berdasarkan tempat file berada. Chapter ini — sekaligus penutup section — menyusun proyek mini kita menjadi wujud akhirnya.

Layout Standar Proyek C++ #

Tidak ada standar baku yang dipaksakan compiler, tetapi komunitas C++ konvergen pada satu pola yang hampir selalu Anda temui di proyek open source:

text 
kalkulator-geometri/
├── CMakeLists.txt
├── README.md
├── include/
│   └── geometri.h        ← antarmuka publik library
├── src/
│   └── kalkulator.cpp    ← aplikasi pemakai library
├── tests/
│   └── tes-geometri.cpp  ← program tes ala Chapter CTest
├── docs/
│   └── desain.md
└── build/                ← hasil build, tidak ikut di-commit

Lima folder itu masing-masing punya kontrak yang dipahami orang dan alat:

  • include/ — header antarmuka publik yang boleh di-include oleh pemakai di luar proyek.
  • src/ — semua file .cpp dan header internal; dapur yang tidak wajib dipamerkan.
  • tests/ — program tes, ditempatkan sejajar dengan kode yang diuji atau di folder sendiri.
  • docs/ — dokumen desain dan catatan penggunaan, hidup di repositori yang sama dengan kodenya.
  • build/ — semua hasil kompilasi; konvensi out-of-source build dari Chapter CMake.

Dengan konvensi ini, CMakeLists.txt cukup menunjuk dua folder — target_include_directories ke include/, source ke src/ — dan seluruh proyek bisa dijelaskan ke orang baru dalam satu menit.

Header di include/, Source di src/ #

Aturan paling sering ditanyakan pemula adalah penempatan header. Kebiasaan yang sehat: header yang mendefinisikan antarmuka publik — yang boleh dipakai orang lain — tinggal di include/; header yang hanya dipakai antar file .cpp internal boleh tinggal di src/, sejajar dengan penggunanya. Dengan begitu, isi include/ berfungsi sebagai katalog: apa pun yang tidak ada di sana bukan janji API Anda.

Program pemakai library geometri tidak berubah bentuk dari Chapter CMake Dependencies — hanya saja kini #include "geometri.h" diselesaikan lewat folder include:

cpp include/geometri.h 
#pragma once

#include <numbers>

// Library mini geometri — header-only: semua fungsi inline di header.
inline double luasPersegi(double sisi) {
    return sisi * sisi;
}

inline double luasSegitiga(double alas, double tinggi) {
    return alas * tinggi / 2.0;
}

inline double luasLingkaran(double jariJari) {
    return std::numbers::pi * jariJari * jariJari;
}
cpp 
#include <iostream>
#include "geometri.h"

int main() {
    std::cout << "Kalkulator geometri\n";
    std::cout << "Luas persegi 5 x 5   : " << luasPersegi(5.0) << "\n";
    std::cout << "Luas segitiga 8 x 3  : " << luasSegitiga(8.0, 3.0) << "\n";
    std::cout << "Luas lingkaran r = 4 : " << luasLingkaran(4.0) << "\n";
    return 0;
}

Output yang Dihasilkan:

text 
Kalkulator geometri
Luas persegi 5 x 5   : 25
Luas segitiga 8 x 3  : 12
Luas lingkaran r = 4 : 50.2655

Supaya contohnya bisa diuji berdiri sendiri, bundle chapter ini meletakkan kedua file sejajar — dan kompilasi di atas memang dijalankan apa adanya. Dalam layout sungguhan seperti tree di atas, kalkulator.cpp tinggal di src/ dan header ditemukan lewat flag -I:

bash 
g++ -std=c++23 -Wall -Wextra -Iinclude src/kalkulator.cpp -o build/kalkulator

Flag -Iinclude menambahkan folder include/ ke daftar pencarian header — pekerjaan yang di CMake dinyatakan sebagai target_include_directories, sehingga compiler mengambilnya dari properti target, bukan dari flag yang diketik tangan. Mekanisme pencarian lengkapnya (folder sumber dulu, baru folder dari -I) adalah aturan yang sama yang sudah kita pakai diam-diam sejak Chapter Header dan Source Files.

Folder Pendukung: tests, docs, build #

Folder tests/ memanfaatkan seluruh pelajaran Chapter CTest: setiap program tes tinggal di sana, didaftarkan lewat add_test, dan dilari ctest dari folder build. Penamaan yang konsisten — tes-<modul>.cpp, sebagaimana tes-diskon.cpp dan tes-kata.cpp di chapter itu — membuat pola glob seperti tes-*.out tetap bekerja tanpa suntingan.

Folder build/ satu-satunya yang isinya hasil generator, dan karena itu satu-satunya yang tidak masuk repositori — cukup satu baris .gitignore untuk menahannya. Membersihkan seluruh hasil build kini sama dengan menghapus satu folder, dan folder source tetap bersih dari .o maupun executable.

Flat atau Nested #

Apakah proyek kecil wajib memakai semua folder itu? Tidak. Untuk program satu-dua file, layout flat — semua file di satu folder — lebih jujur:

text 
konversi-suhu/
├── konversi-suhu.cpp
└── README.md

Kalaupun bertumbuh menjadi tiga-tiga file dengan header, penempatan sejajar masih masuk akal — dan #include "geometri.h" tetap ditemukan karena header bersebelahan dengan pemakainya. Saatnya naik ke layout bertingkat bila salah satu dari ini terjadi: proyek punya lebih dari satu target (library plus aplikasi, plus tes), orang lain akan memakai library-nya, atau pencarian “file X ada di mana” mulai butuh scroll. Indikator paling praktis: bila folder root sudah lebih dari sekitar sepuluh file campuran, isi ulang.

Rangkuman Section Build System dan Project Structure #

Perjalanan tujuh belas chapter section ini bisa dirangkum dalam empat babak:

  • Memecah kode — header memisahkan antarmuka dari implementasi (Header dan Source Files, Declaration vs Definition); include guard dan #pragma once membuat include boleh terjadi berkali-kali tanpa redefinisi; separate compilation menyimpan kerja kompilasi dalam object file.
  • Menyambung kode — linker mencocokkan simbol antar object file (Linking dan Symbols), dan library mengemasnya untuk dipakai ulang, statis maupun dinamis (Static dan Dynamic Libraries).
  • Mengotomatiskan — make mengeksekusi aturan incremental (Make dan Makefile); CMake menghasilkan build system untuk semua platform (CMake, CMake Targets); dependensi masuk lewat add_subdirectory, find_package, dan FetchContent (CMake Dependencies), dipasok manajer paket (vcpkg, Conan) dalam strategi yang dipilih sadar (Dependency Management).
  • Menjaga mutu — CTest mengadili program dari exit code-nya (CTest), build type menentukan jaring pengaman dan kecepatan (Build Types dan Optimization), dan layout merapatkan semuanya menjadi satu struktur yang bisa dinavigasi.

Satu benang merahnya: setiap alat di section ini bekerja karena kontrak yang tertulis secara eksplisit — deklarasi di header, simbol di object file, target di CMakeLists, versi di manifest, harapan di program tes. Proyek yang sehat adalah proyek yang kontraknya bisa dibaca siapa pun dari struktur foldernya sendiri.

Dengan wujud proyek sudah utuh, pertanyaan menariknya bergeser dari “file ini taruh di mana” ke pertanyaan yang lebih dalam: bagaimana membagi program menjadi modul-modul dengan batas tanggung jawab yang jelas, sehingga antarmuka yang kita pajang di include/ memang layak dipajang. Itulah arah Section berikutnya — Modularity dan Software Design.

Referensi: target_include_directories .