Comment by epage
2 years ago
> The one goal of the port we did not succeed in was removing CMake.
> That’s because, while cargo is great at building things, it is very simplistic at installing them. Cargo wants everything in a few neat binaries, and that isn’t our use case. Fish has about 1200 .fish scripts (961 completions, 217 associated functions), as well as about 130 pages of documentation (as html and man pages), and the web-config tool and the man page generator (both written in python).
Our issue for this is https://github.com/rust-lang/cargo/issues/2729
Personally, I lean away from Cargo expanding into these use cases and prefer another tool being implemented on top. I've written more about this at https://epage.github.io/blog/2023/08/are-we-gui-build-yet/
(hi Ed!)
I would definitely love to see Cargo have the ability to do this -- it means that `cargo install --locked` stays as a viable approach. It probably won't apply to fish, but I think being able to run a post-install command from the binary you just installed would suffice for my needs.
We've actually added support to make single-binary fish deployments possible by (optionally) bundling static resources that would be part of the CMake-based deployment into the binary itself and having it unwrap those on first execution. The limitations of Cargo and the idiomatic `cargo install` usage primarily motivated this.
I'm a big fan of this solution! It's always been annoying to perform all the ceremony involved in deploying a system with a bunch of files, with config, scripts and system written in a bunch of different languages.
In my current project I just wrote the installer and config generation as part of the main method. Gets rid of a lot of complexity, with a simpler build, and is arguably easier to maintain. Single language, single binary.
Ah interesting, I looked through your build.rs for the "installable" feature, and it looked like you were running sphinx-build in there. Do you plan to ship those artifacts in the .crate file?