laze
laze copied to clipboard
kaspar030
A fast, declarative build system for C/C++ projects, based on Ninja
E.g., the riot-rs Cargo link-only "apps" don't invoke custom build rules for any selected modules.
This enables some nifty features: - [ ] allow modules to define Rules - [ ] allow modules to define Tasks - [x] conflict a context This also implies that...
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...
At least, - [ ] git - [ ] local path Nice to have: - [ ] git shortcuts - [ ] gh:org/repo - [ ] gl:org/repo - [ ]...
Current sketch: - `tasks:` added to a module - every module that defines a task implicitly `provides_unique` a magic name, e.g., `::task::`
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...
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.
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 -...
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...
I tried to import another laze file in my `laze-project`: ```yml imports: - git: url: https://github.com/future-proof-iot/RIOT-rs commit: 3880b249564a249d6cd52b5aedc52597d35882bb apps: - name: hello-world selects: - ?release ``` This fails with: ```sh...
