Project layout
What ignis init writes, and every section of the ignis.toml manifest.
A project is a directory with an ignis.toml at its root. Every compiling command finds it by
walking up from the working directory, which is why ignis build works from anywhere inside the
tree.
ignis init hello-app # binary project
ignis init mylib --lib # library project
ignis init . # initialize the current directory
ignis init scratch --no-git # skip the git init that otherwise runs
init writes the manifest and an entry file — src/main.ign for a binary, src/lib.ign for a
library — and never overwrites an existing one.
Where init points std
The generated std_path is resolved in order:
IGNIS_STD_PATH, if it is set and the directory exists.../std, relative to the project root, if it exists.- Neither, in which case
std_pathandruntime_pathare left out entirely.
runtime_path is written only when <std_path>/runtime exists. If a fresh project cannot find the
standard library, this is the setting to check first.
The manifest
[package]
name = "myapp"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
description = "My Ignis project"
keywords = ["ignis"]
license = "MIT"
repository = ""
[ignis]
std = true
std_path = "../std"
runtime_path = "../std/runtime"
[build]
bin = true
source_dir = "src"
entry = "main.ign"
out_dir = "build"
opt_level = 0
debug = false
target = "c"
cc = "cc"
cflags = []
emit = []
[package]
Metadata: name, version, authors, description, keywords, license, repository. The
name is what the produced binary is called.
[ignis]
std turns standard library support on. std_path and runtime_path point at their roots; if
runtime_path is omitted the resolver falls back to <std_path>/runtime.
[build]
| Key | Meaning |
|---|---|
bin |
true for an executable, false for a library |
source_dir |
Source directory, relative to the project root |
entry |
Entry file, relative to source_dir |
out_dir |
Where build output lands |
opt_level |
Optimization level, 0 to 3 |
debug |
Include debug information |
target |
Backend — the project resolver accepts only "c" today |
cc |
The C compiler to invoke |
cflags |
Extra flags passed to the compiler and linker |
emit |
Extra artifacts to keep: "c", "obj" |
A binary project sets bin = true with entry = "main.ign"; a library sets bin = false with
entry = "lib.ign".
[formatter]
The four settings ignis fmt reads, documented in formatter. They can
also live in a dedicated ignisfmt.toml, which takes precedence over this section.
[aliases]
Import path aliases. Each key is matched against the first segment of an import path, each value is a directory relative to the project root or absolute.
[aliases]
mylib = "libs/mylib"
ext = "../external/packages"
With that, import Foo from "mylib::utils" resolves to libs/mylib/utils.ign, or
libs/mylib/utils/mod.ign when that directory exists.
Four rules that bite:
"std"is reserved and cannot appear here.- An alias path must point at a directory that exists.
- Only the first segment is matched —
mylibinmylib::sub::mod. - Single-file builds ignore user aliases. Only the implicit
stdalias works there.