kaspar030/laze

A fast, declarative build system for C/C++ projects, based on Ninja

Introduction

Welcome to laze, a ninja build file generator. Aspires to be the next goto-alternative to make.

Installation

Install the ninja build tool using your distro's package manager, then install laze using cargo:

$ cargo install laze

Getting started

$ laze -C examples/hello-world build run

Documentation

Please take a look at the manual. It is still incomplete, but being worked on.

License

laze is licensed under the terms of the Apache License (Version 2.0).

laze's Issues

feat: cross-app dependencies

Currently, all dependency resolution is within one app/builder pair.

There are use cases for crossing that boundary:

• an application might want to build with a previously built library
• a RIOT application might need to be turned into a .bin, combining output from a bootloader application and a user application

feat: task dependencies

Tasks could have dependencies.

E.g., a "run-with-qemu" task could depend on a "qemu-config" module, and only be available if that module is.

-v output is not shell-escaped

For running different cargo commands, I extracted what laze calls by running

$ laze -C examples/application build -v -b microbit-v2 -s probe-rs-run run
laze: project root: /home/chrysn/git/crates/RIOT-rs relpath: examples/application project_file: laze-project.yml
laze: building all for microbit-v2
laze: reading cache took 3.067268ms.
laze: executing task run for builder microbit-v2 bin application
+ cd examples/application
+ RIOTBASE=../../ BOARD=microbit-v2 USEMODULE= NEWLIB_ARCH=thumb/v7e-m/nofp CFLAGS= CFLAGS_OPT=-Os EXTERNAL_MODULE_DIRS= LTO=1 BUILDING_RIOT_RS=1 OPENOCD_ARGS=-f board/nordic_nrf52_dk.cfg SCRIPTS=../../scripts CARGO_BUILD_TARGET=thumbv7em-none-eabi CARGO_TARGET_THUMBV7EM_NONE_EABI_RUNNER=probe-rs run --chip nrf52840_xxAA CARGO_TARGET_THUMBV7EM_NONE_EABI_RUSTFLAGS=-Clink-arg=--nmagic -Clink-arg=-Tlinkme.x -Clink-arg=-Tlink.x -Clink-arg=-Tdevice.x -Clink-arg=--no-eh-frame-hdr --cfg builder="microbit-v2" -Clink-arg=-Tisr_stack.x --cfg context="cortex-m" -Ctarget-cpu=cortex-m4 --cfg armv7m --cfg context="nrf52" --cfg context="nrf52840" -Cembed-bitcode=yes -Clto=fat -Ccodegen-units=1 CARGO_TARGET_DIR=../../build/bin/microbit-v2/application/cargo cargo run --release --features=riot-rs-boards/microbit-v2,riot-rs/silent-panic,riot-rs/debug-console

... but cop-pasting the line starting with RIOTBASE=, my shell threw an error because escaping was off -- it says OPENOCD_ARGS=-f board/nordic_nrf52_dk.cfg which comes across to the shell as setting OPENOCD_ARGS to -f and then calling board/nordic_nrf52_dk.cfg. laze clearly has this right internally (the right command is called), but appears to naively print the shell arguments space-separated without extra escaping.

I'm too deep somewhere else in the stack to PR it, but I've found the shlex crate useful for escaping strings for shells when arguments can't be passed to an exec() call.

feat: basic expression evaluation

e.g., allow a variable to be $(max(1,5)), or $(dirname $(outfile)).

feat: chain or postprocessing rules

Currently, "apps" produce .elf files. RIOT needs, for some targets, add creation of a bootloader image as step after linking.
This can be worked around by doing the necessary steps in a task, but that's suboptimal.

bug: `${relpath}` from imported definitions sometimes empty in project root

... should be .

cosmetic: discuss naming of things

Currently, laze uses

• context
• builder: maybe change to "target"? Is that ambiguous with a "make target" (or "ninja target", which refers to a build output?
• apps: not everything laze builds might be an application. think libraries, pdfs, ...
• modules: components, ...?

I'm OK with these, but maybe better names pop up. Input very welcome!

feat: better support for generating source code

Use cases:

• blobs
• generated sources, e.g., turn a something.proto into source code that then gets compiled

These can already be expressed using custom build rules, but IMO that's too clumsy to be usable.