cargo-c VS cargo-make

I'm writing this to explain some of the problems cargo-c solves and hopefully give few pointers since the README containing all the documentation maybe grew to be fairly big.

Beside rav1e there is need also for cargo-c, so that rav1e can provide C-compatible library.

Well, I don't use makefiles to deploy software with Rust. I also have never used lex or yacc, but I bet there are similar tools in the ecosystem, or wrappers for those. That would obviate what I will offer below.

Often a new language in a project would define an application boundary. So those would be different containers or services. I may deploy via container images, or an OS specific installer, etc. If we aren't crossing an application boundary I may use FFI. Sometimes I use https://rust-lang.github.io/rust-bindgen/ to smooth that over for C dependencies. There is also a nice concept called a build.rs file: https://doc.rust-lang.org/cargo/reference/build-script-examp.... There's also tools like: https://github.com/casey/just and https://sagiegurari.github.io/cargo-make/

I rarely use multiple languages with Rust. A lot of interpreted languages have bindings through crates and can go in to a project through Cargo. If it involves JS/TS on desktop, I'm usually using Tauri for that. Guess it depends on the system?

Hopefully that helps. You can also still use a Makefile if you want I just haven't dealt with one in a long time.

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