Project configuration

Everyday workflow

sere init hello
cd hello
. .\scripts\activate.ps1
sere build
sere run
sere run first second
sere build --emit-llvm -o bin/hello.ll
deactivate

build compiles the configured entry, and takes the compiler options (--backend=serem, --no-transformers, --emit-llvm, --emit-asm, --opt=O2, -O3, --release, -o <path>, …) the same way a direct sere <file.sere> build does. run builds the executable and then executes it: every argument after run is passed to the program, including arguments that look like compiler flags. Write compiler options before the command word (sere --opt=O2 run first second) when you need them. Dot-source activation to use the current terminal.

Build settings come from three places, in this order: the command line, then the manifest, then the O0 default. A command-line switch always wins, so sere build -O3 --release overrides opt in sere.toml for that build. See optimization.md for every switch.

Start with the getting-started walkthrough for a complete program and a local module.

Manifest settings

New applications and libraries use these sections in sere.toml:

[project]
name = "hello"
version = "0.1.0"
kind = "app"                 # app or lib

[toolchain]
sere = "pre-0.1.5"

[paths]
src = "src"
entry = "src/main.sere"
libs = "libs"
stdlib = "venv/stdlib"

[build]
output = "bin/hello.exe"     # omit to select the platform default
opt = "O0"                   # O0, O1, O2, O3, Os, Oz
native = false              # build libs/native

[tool.example]
name = "custom metadata"     # does not override project.name

Paths resolve relative to sere.toml. Libraries use kind = "lib", entry = "src/lib.sere", and default to dist/<name>.slib. Unknown keys and custom tables are reserved for extensions and ignored by Sere. The compiler reads scalar string/boolean settings; it does not interpret custom arrays or tables. Single-quoted literal paths are useful for Windows paths. Legacy manifests with the same keys at the root remain supported. sere update edits the toolchain version without replacing custom settings.

Virtual environments contain one stdlib tree at venv/stdlib, including real module subdirectories. Legacy nested copies named stdlib/stdlib are excluded when copying a toolchain. The compiler tools are shared with the installation recorded in venv/sere.cfg, so each project does not duplicate LLVM or the SDK.

Packing and consuming libraries

From a directory containing your application project hello:

sere init-lib mathlib
cd mathlib
sere pack
Copy-Item dist/mathlib.slib ../hello/libs/
cd ../hello
sere build

A library uses src/lib.sere as its default entry. Put its public functions and types there; a library does not need an application main. Consumers use import mathlib or from mathlib import add for an exported add function.

sere build also packs projects with kind = "lib". To package one module without a manifest, use sere pack helpers.sere -o helpers.slib. Packing includes the entry, the local modules it imports, and compiled native objects. Unused neighboring source files are excluded.

An unpacked libs/mathlib/lib.sere or libs/mathlib/mathlib.sere also provides import mathlib. See modules and imports for exports and resolution, and native interop for C bindings. Repack and rebuild consumers after changes to compiled library code.

Inspecting and refreshing the environment

Get-Command sere
sere --version
sere --print-env

Use these commands to identify the executable and paths currently in use. sere update copies the compiler you invoked to the per-user installation when it differs and refreshes the current project's environment. It does not download a release: invoke it from the compiler version you want to install. sere refresh-bin copies the running compiler, runtime, and stdlib into ./bin.

sere clean removes the project's bin/, dist/, native build directory under libs/native/build/, and extracted library cache under libs/.sere-lib/, then recreates bin/. Keep source and hand-maintained files outside those directories.

Troubleshooting