You can see all the [hidden] default tasks with

cargo make --list-all-steps

and if you want to know what is going on, you can

cargo make --verbose -- coverage | save result.json

in nushell to save the result to a file

I've always been curious as to why espanso encourages external build tools at all -- it seems like it increases the complexity of the build process, and I'm not sure what the upside is. For example, on macOS, I just ignore cargo make and build with the standard cargo tooling -- the compilation succeed and the binary works as expected.

Is it just for the extra steps of e.g. creating Espanso.app? If so, wouldn't something like a simple bash script or Makefile do the job (and be much less likely to break or become unmaintained in the next year or two)?

One of the only parts of rust that I don't care for is how the small standard library leads to lots and lots of external dependencies, which IME have a poor track record of being maintained over time. I'm definitely of the camp that tries to minimize external dependencies when I can!

Nice point. This test was introduced by my frustration using cargo-make, which I consider still unintuitive at its latest version. I wanted to cargo build and be done for the day, but the different binaries teached me that it can't be possible.
Problably this lead to this PR in a intent to simplify the API to build the software using just, but you are correct in we are just using another tooling.
If we take a couple of steps back, we need from the codebase:

• to compile a binary in different platforms
• 2 of them for Linux, one for Wayland (increasingly common) and one for X11 (currently the default)
• 1 for windows
• and 2 for mac (older and newer architecture)

in addition, this binary has to be packaged in different formats

• installable and portable for windows
• homebrew and appbundle for macOS
• in AppImage, redhat packages (WIP) and debian packaging (dpkg) for linux
• as a last resort, it's available to manual compiling for users

This is even more difficult because you need to compile everything above with different scripts (bash, zsh or powershell). There is no silver bullet here.
I really want to escape this reality, but I don't see any better way than trying to streamline with a script manager (just or cargo-make) all we can. What are your thoughts?

I really want to escape this reality, but I don't see any better way than trying to streamline with a script manager (just or cargo-make) all we can. What are your thoughts?

Thanks for a thorough response. I agree on all points that it's a tough issue!

I think my preference would be to use neither if possible:

• I think either make or just a bash script should be adequate to fill these needs on macOS or Linux (but I don't have a Windows machine -- so not sure how that works or fails to)
• Either make or a bash script is going to have a much longer history of stability and a much lower risk of becoming unmaintained; any time we invest in getting it working should be time that stays well-spend for decades
• The only caveat I can think of is if the above approach is prohibitively difficult on Windows
• In that case, one other option would be to write this tooling directly in Rust (possibly even using the new -Zscript nightly feature?) avoiding external tooling entirely

I have no further interest in just. It's a great tool, but for everyday use, I just use nu scripts, so closing