I was thinking about this more like the scripting section in nodejs, that allows to have several events, like a pre-build, post-build, etc, it occurred to me that this can help to configure git-hooks, installation of dependencies or generation of certain code or files in certain events, I would like to read suggestions of how it would be an implementation of this in cargo, I had thought something like this
# ...
[scripts]
pre-build = [
["cargo:test"], # This is a internal command
["cargo:clippy", "-D", "warnings"]
]
custom = [
["cargo:test", "cargo:fmt", "cargo:clippy", "ls -la"]
]
Then to run the script, it would be with the same run command, only that internally it would check first if there is any script with that name and if not, it simply compiles and runs the application binary, like this
# Run binary application
cargo run
# Run script
cargo run custom
The way to define the commands is still something that I came up with quickly and I am open to ideas, I would like to hear what you think to start working on this feature
Cargo doesn't have the concept of pre-build or post-build scripts. There is the concept of build scripts, but they are bound to a specific package rather than project and run for all dependencies before compiling the respective crate. As for
# Run script
cargo run custom
there are two options. You can add an extra binary to your project and run it with cargo run --bin custom, but this will compile all dependencies of the main project first too, or you can use the [alias] section in .cargo/config.toml and then run it like cargo custom.
Ooooo, this is similar to what I would like to do, but I was thinking that somehow these aliases or scripts would be executed on some charge event, for example on first build, do pre config
That actually works quite well, thanks for demonstrating this by the way. It really made me wonder if cargo should be distributed with a component containing some pre-compiled libraries for interacting / parsing the cargo metadata output (similar to a std extension) because the compile times go up quite considerably if the xtask needs to consume those structures. Then it would be much more effective to use an xtask as a supplement consuming the declarative Cargo.toml description. Personally, I've wanted to download additional test data that shouldn't be contained in the crates-io archive. The xtask works but it seems just a slight bit sluggish at first.
Also, of course, the xtask won't interact with the job queue in a more complex project. Oh well, good enough at the moment.
Yeah, I just usually shell out to cargo metadata to get a string, and then do a string search therein. Another hack is that, to get version from Cargo.toml, I shell out to cargo pkgid. If cargo contained some plumbing commands so that I can run cargo metadata --query "dependencies" and get result as a list of strings, that would simplify a bunch of tasks.
Alternatively, I am fairly certain that it's possible to implement a version of https://docs.rs/cargo_metadata/latest/cargo_metadata/ which is massively more lightweight, by not depending on serde ecosystem, and just pre-generating all parsing code for a fixed structure it has to deal with.
That... actually I think is a project the ecosystem could benefit quite a bit I think.
Even just using miniserde would be an interesting alternative. While it'd still pull in syn, it'd still be significantly lighter (and theoretically easier to cargo expand away).
Yeah, to spell this more explicitly, the problem in this particular case is not syn, but serde. Serde infra is generic over both the serialization format and the data structure being parsed.
In the case of cargo-metadata, both are fixed, emoting specialized parsing code for them should improve compile times a lot, mainly by ensuring that the logic is monomorphic and is codegened in the upstream crate once.
