duckscript VS cargo-make

Currently i'm using it in cargo-make but will also use it later to parse args for duckscript commands.

At it's most basic you could make a really simple interpreter by just doing such a thing, and there is essentially already such a simple language like that built for/in rust called Duckscript (rust has a surprisingly large number of little embedded languages), and that would be completely and entirely sufficient for many purposes, though if you want speed then you'll need to JIT or AOT the code, which is why wasm is so handy as you can interpret or JIT (or even AOT it with wasmer) without the much larger overhead of a, for example, javascript or java embedded runtime.

cargo-make aims to be an extensive Rust-written task runner that additionally lets you define workflows to execute your tasks. You can install it using cargo install cargo-make.

You might be interested in cargo-make, which is based on TOML, or Just, which has a syntax that is vaguely inspired by Make but much less weird sigils and more suited to non-file-based tasks.

I would like to rewrite this project in Rust, but I am not so familiar with Cargo as I am with Make. Is it possible to declare these kinds of rules and targets ? Should I use a build script, a custom tool like cargo-make or something else ? What do you think ?

I use just myself, and I personally don't want projects' codebase to decide when something gets cargo installed on my system. For people who feel that's more acceptable, I'll note that cargo-make has first class support for the idea of expressing a task that depends on a cargo plugin:

Thank you for the help, created ticket #787 and #788!

https://github.com/sagiegurari/cargo-make

I ended up using it over just because it felt easier to use cross platform, and toml seemed like a right choice

cargo make is used pretty extensively in Bottlerocket OS

Cargo is a pretty robust build tool on it's own, but for that extra automated workflow oomph, I also use cargo-make