WIP: Use xtask as build system
#2012
Conversation
|
@imsnif Here's my xtask proposal PR. It's not entirely done yet (see description above). If you like, you can try and test it: It's already capable of most things (I think) we need. The available commands can be found with If you think there's something missing I haven't covered above, please let me know! Curious to hear if you spot the "bonus" I added in terms of telling which command/task is currently being run... |
|
@har7an - I've got a lot on my plate atm. Would be happy to give some specific feedback if you have any questions or are unsure of something? Otherwise I'd rather give it all a thorough look when you're positive it's good, finished and does everything it needs to. |
bb8b168
to
deb0921
Compare
|
@imsnif It's done now. As far as I can tell it has full feature-parity with previous |
|
Hey @har7an - this already looks great! Looking forward to using this. A few comments:
|
Good catch, I forgot a
Have you tried running
I see. I added a Oh btw, great "feature" about xtask (although irrelevant for you): #1929 doesn't occur any longer. :) |
xtask is a cargo alias that is used to extend the cargo build system with custom commands. For an introduction to xtask, see here: https://github.com/matklad/cargo-xtask/ The idea is that instead of writing makefiles, xtask requires no additional dependencies except `cargo` and `rustc`, which must be available to build the project anyway. This commit provides a basic implementation of the `build` and `test` subcommands.
to perform different useful tasks. Includes: - clippy - format - "make" (composite) - "install" (composite) Also add more options to `build` to selectively compile plugins or leave them out entirely.
- `wasm_opt_plugins` and - `manpage` that perform other build commands. Add thorough documentation on what each of these does and also handle the new `build` cli flags appropriately.
that perform multiple atomic xtask commands sequentially in a pipeline sort of fashion.
and add documentation.
which performs an 'install' and copies the resulting zellij binary along with some other assets to a `target/dist` folder.
to pass all arguments following `xtask run` directly to the zellij binary being run.
and make all tasks that need it change to the project root dir themselves.
which will allow very quick iterations when not changing the plugins between builds.
52ed2e1
to
a588bb7
Compare
74da1a5
to
9dd4c1a
Compare
because the zellij binary needs to include the plugins.
d6acb24
to
7eec160
Compare
Moves the build system away from
cargo maketocargo xtask.Rationale
cargo makeisn't an ideal buildsystem for zellij for a number of reasons:utils) this means that in fact we build the plugins about 10 times in a singlecargo buildcargo makeproduces a lot ofcargo make-specific output for little program output. This often makes it hard to follow what task exactly failed and on which workspace memberAlso, the recent release showed that clearly we hit some boundary with
cargo makeand the way we're using it. So it is probably time to think about an alternative.Why
xtaskcargo xtaskisn't so much a tool on its own as a member of the project workspace. It is a subcrate inside the project, which runs project-specific tasks. This has a great benefit: It needs no additional dependencies.cargo xtaskis compiled as a rust binary and then parses all other arguments.It is neither a recommended workflow, not a de-facto standard. The "website" can be found here: https://github.com/matklad/cargo-xtask
It is used by other influential rust projects, such as rust-analyzer. The benefit for zellij is that we can customize it more easily and adapt it to our changing requirements. This is especially important since with the plugin system we need to handle some added complexity otherwise missing in "regular" rust projects.
Current state
There are still a few things compared to
cargo makethat it isn't capable of (yet):cargo make runorcargo make test, where developers can currently pass any additional CLI args at the end, which are passed through to the application. I'm still looking for a way to do this...cargo make publishflowAlso I'd like to add another cargo alias/deprecation warning for users still using
cargo maketo inform them of the new build system.