04.2 Compilation units
What gets compiled per target, entry modules, and dependency compilation order.
Compilation units
A target selects an entry and pulls in the module graph needed to build it. You do not “compile the repo” as an undifferentiated blob, unless you enjoy O(n²) surprise.
Entry-driven builds
Section titled “Entry-driven builds”target.entry points at a .bd file under project.root. That entry module anchors reachability analysis: dependencies of the target plus transitive modules from path dependencies.
flowchart BT accTitle: Compilation unit reachability accDescr: The entry file imports other modules, which can reach a path dependency library. E[entry Main.bd] --> M1[imports / uses] M1 --> M2[other modules] M2 --> DEP[path dependency Lib]
Libraries vs apps
Section titled “Libraries vs apps”App: you care about runnable output and main lifecycle.Lib: you care about exported surface consumed by other projects.Test: harness entry; keeps test-only modules out of production graphs when structured well.
Multiple targets, multiple graphs
Section titled “Multiple targets, multiple graphs”Targets can share source files but differ in entry and dependency sets. Changing one target’s entry does not magically retarget another: pass --target explicitly, always.
Analyzer vs builder
Section titled “Analyzer vs builder”beskid dev syntax analyze and beskid dev build compile share semantic understanding; failures should reproduce across CLI and LSP when roots match. Start analysis on the smallest target while learning.