Targets and outputs

Informative guide. This Book page explains Beskid but does not define the standard. For normative requirements, use the Beskid Standard.

Targets are how you tell the truth about what gets built. A repo without targets is just a folder that gaslights CI.

Target kinds

kind	Typical use
App	Executable entry (entry → main module file)
Lib	Library surface consumed by dependents
Test	Test harness entry for beskid test

kind and source on dependencies are enum-like—prefer unquoted identifiers (App, path) for tooling alignment.

Entry paths

entry is relative to project.root (default Src). If you set root = "src" because you hate consistency, every entry path moves with it—do not mix mental models.

Multiple targets

Real projects often define both App and Test (and several libs). CLI commands accept --target to select which graph root you mean:

beskid build --project ./App.bproj --target App
beskid test --project ./App.bproj --target Tests

accTitle: Project targets and dependencies
accDescr: One bproj manifest defines application and test targets that share the resolved dependency graph.
flowchart TD
  P[App.bproj] --> T1[target App]
  P --> T2[target Tests]
  P --> D[dependencies]
  D --> T1
  D --> T2

Text equivalent: App.bproj defines the App and Tests targets. Both targets consume dependencies from the same resolved project graph.

Outputs and obj/

Materialized dependencies land under obj/beskid/ (layout details in build workflow). Treat obj/ as generated unless you enjoy merge conflicts.

Standard reference (informative)

• Project manifest contract
• Build workflow

Next

beskid new