Project manifests

Use kalandra new for a starter, or create the files shown here. The manifest selects the source entry and any local package mappings. It is compiler input, not a file loaded by the generated application.

A minimal application

Use a new working directory. Create my-app/src and save this as my-app/src/main.k:

fn main() -> int:
  6 * 7

Save this manifest as my-app/kalandra.toml:

format = 1

[project]
entry = "src/main.k"

kalandra-check --project my-app/kalandra.toml
kalandra --project my-app/kalandra.toml -o my-app/program
./my-app/program

Select either a source path or --project, not both. There is no implicit ancestor search for a project manifest. Relative entry/package paths resolve from the canonical manifest directory; -o still resolves from the current working directory.

The program returns 42.

Map a local source library

Create my-app/lib, save this library as my-app/lib/geometry.k, and replace the application entry with the second example:

export fn area(width: int, height: int) -> int:
  width * height

from "geometry" import area

fn main() -> int:
  area(6, 7)

Replace my-app/kalandra.toml with:

format = 1

[project]
entry = "src/main.k"

[packages]
geometry = "lib/geometry.k"

Check and build again using the commands above; the result remains 42. Code in the application may then import exported declarations from "geometry". Mapping a name does not make private declarations public. Explicit mappings are offline source locations, separate from managed Git dependencies.

A source library manifest

format = 1

[package]
name = "geometry"
version = "0.2.0"
entry = "src/public.k"

Save that library manifest in a separate library root, with the exported area function above in src/public.k. A source library declares the module callers import and resolves its own dependencies. Its entry and local mappings must stay within its canonical root. Version metadata does not introduce version-range solving.

Build modes

kalandra --project my-app/kalandra.toml -O2 -o program
./program

The optimized CPU program also returns 42. CPU builds produce an executable. GPU builds produce an application directory containing the executable and its backend resources; keep those files together. Shape, numeric and error checks remain part of the native semantics in optimized builds.

• Dependency installation and locks
• Build and run a complete Metal application