[GH-ISSUE #1934] Explore replacing cargo-make with just #822

New issue

Closed

opened 2026-03-16 00:25:59 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 00:25:59 +03:00

Owner

Originally created by @bluejekyll on GitHub (May 15, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1934

Is your feature request related to a problem? Please describe.

Makefile.tomls have been somewhat hard to maintain. Recently publish has broken and requires a lot of changes.

Describe the solution you'd like
Replace with a simpler system based on justfiles in combination with cargo-workspaces

Additional context

cargo-make has provided a very valuable tool for the project in regards to executing operations across all crates in the project. This has improved test coverage, simplified integration with CI in github actions and other systems. This has made for reliable testing of the major features of the project easy to reproduce between CI and CLI. At the same time it is a system which works, but is difficult to understand. By moving to a simpler system, it should allow for more people to contribute to the project.

Originally created by @bluejekyll on GitHub (May 15, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1934 **Is your feature request related to a problem? Please describe.** Makefile.tomls have been somewhat hard to maintain. Recently publish has broken and requires a lot of changes. **Describe the solution you'd like** Replace with a simpler system based on `justfile`s in combination with `cargo-workspaces` **Additional context** `cargo-make` has provided a very valuable tool for the project in regards to executing operations across all crates in the project. This has improved test coverage, simplified integration with CI in github actions and other systems. This has made for reliable testing of the major features of the project easy to reproduce between CI and CLI. At the same time it is a system which works, but is difficult to understand. By moving to a simpler system, it should allow for more people to contribute to the project.

kerem closed this issue

2026-03-16 00:26:04 +03:00

kerem commented

2026-03-16 00:26:19 +03:00

Author

Owner

@djc commented on GitHub (May 15, 2023):

In all of the other projects I help out with, we don't use anything else on top of Cargo itself. What (conceptually) have been the kind of things that you've felt the need for extra tooling? Maybe Cargo has matured since you first started the project and can now handle more stuff out of the box?

@djc commented on GitHub (May 15, 2023): In all of the other projects I help out with, we don't use anything else on top of Cargo itself. What (conceptually) have been the kind of things that you've felt the need for extra tooling? Maybe Cargo has matured since you first started the project and can now handle more stuff out of the box?

kerem commented

2026-03-16 00:26:24 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 15, 2023):

We have a lot of features in the project, that I've found difficult keeping working on their own without an easy way to reproduce the options to each crate to enable and disable them as necessary. I've found that keeping that in some script helps make things more consistent and doesn't require looking at CI scripts for identifying the options for what is failing.

cargo-make had done a great job of that so far. On top of that, publishing had been nicely handled before without missing any crates. So I'd like to get that feature set back. Other things that were encoded properly in there have been code-coverage execution and installation for various tools, like bind for compatibility testing or openssl on windows. Overall, there end up being a lot of things that are basic scripts, that Makefile, justfile, or Makefile.toml make maintaining that simpler IMO.

For users of the project, generally, standard cargo commands will just work without issue.

@bluejekyll commented on GitHub (May 15, 2023): We have a lot of features in the project, that I've found difficult keeping working on their own without an easy way to reproduce the options to each crate to enable and disable them as necessary. I've found that keeping that in some script helps make things more consistent and doesn't require looking at CI scripts for identifying the options for what is failing. cargo-make had done a great job of that so far. On top of that, publishing had been nicely handled before without missing any crates. So I'd like to get that feature set back. Other things that were encoded properly in there have been code-coverage execution and installation for various tools, like bind for compatibility testing or openssl on windows. Overall, there end up being a lot of things that are basic scripts, that Makefile, justfile, or Makefile.toml make maintaining that simpler IMO. For users of the project, generally, standard cargo commands will just work without issue.

kerem referenced this issue

2026-03-16 02:21:24 +03:00

[PR #822] [MERGED] Bump tokio-executor from 0.1.7 to 0.1.8 #1714