# A list of commands to pre-configure the project **URL:** \ **Category:** cargo\ **Created:** [October 5, 2022, 6:10am UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492 "2022-10-05T06:10:12Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![SergioRibera](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sergioribera/32/9892_2.png) [@SergioRibera](https://internals.rust-lang.org/u/SergioRibera)\ **Post date:** [October 5, 2022, 6:10am UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/1 "2022-10-05T06:10:12Z")
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 ```nohighlight # ... [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 ```nohighlight # 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 😃 ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [October 5, 2022, 6:38am UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/2 "2022-10-05T06:38:39Z")
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 ```rust # 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`. ---
**Author:** ![SergioRibera](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sergioribera/32/9892_2.png) [@SergioRibera](https://internals.rust-lang.org/u/SergioRibera)\ **Post date:** [October 12, 2022, 12:36pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/3 "2022-10-12T12:36:56Z")
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 ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [October 12, 2022, 12:43pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/4 "2022-10-12T12:43:00Z")
Please don't modify the operating system (non-cargo dependencies) from a `cargo build`. For things like tests and clippy, I suggest using a `Makefile`. For pure-rust tasks, there's a concept/hack xtask: > **[GitHub - matklad/cargo-xtask](https://github.com/matklad/cargo-xtask)** > > Contribute to matklad/cargo-xtask development by creating an account on GitHub. ---
**Author:** ![SergioRibera](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sergioribera/32/9892_2.png) [@SergioRibera](https://internals.rust-lang.org/u/SergioRibera)\ **Post date:** [October 12, 2022, 1:07pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/5 "2022-10-12T13:07:51Z")
Precisely my idea was to avoid using external tools, but the library you mention sounds pretty good, thank you very much ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [October 12, 2022, 1:18pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/6 "2022-10-12T13:18:21Z")
> [@SergioRibera](#): > > but the library Important point of note is that xtaks is _not_ a library or a custom sub command. It's just the curious way to use built-in Cargo functionality. ---
**Author:** ![197g](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/197g/32/7276_2.png) [@197g](https://internals.rust-lang.org/u/197g)\ **Post date:** [October 12, 2022, 3:02pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/7 "2022-10-12T15:02:10Z")
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. ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [October 12, 2022, 3:16pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/8 "2022-10-12T15:16:20Z")
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. ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [October 14, 2022, 4:17am UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/9 "2022-10-14T04:17:31Z")
Even just using [miniserde](https://lib.rs/crates/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). ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [October 14, 2022, 7:48am UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/10 "2022-10-14T07:48:40Z")
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. ---
**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\ **Post date:** [December 22, 2024, 5:23pm UTC](https://internals.rust-lang.org/t/a-list-of-commands-to-pre-configure-the-project/17492/11 "2024-12-22T17:23:11Z")
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.