cargo-xtask

macros generally have a regular library they generate code against - lower development overhead to develop them together, e.g. anstyle has a lot of related packages and I wouldn't be wanting to maintain a repo per package Packages also let you mix a library with bins and examples. We talked about multi-purpose packages vs libraries at https://blog.rust-lang.org/inside-rust/2024/02/13/this-devel... (this was before workspace publishing was supported). Something this doesn't mention is that Cargo workspaces allow for sharing parts of the manifest through "workspace inheritance", including package metadata like the repo, dependency version requirements, lint configuration, or compilation profiles.

se it is the default. Please, don't be a special snowflake that decides to do things differently, even with a good reason. The described hierarchy would be super confusing for me as an outsider discovering the codebase. Meanwhile, vs code pretty much doesn't care that there's an intermediate `src` directory. Not naming the root of the crate `lib.rs` also makes it hard to actually find the root component of a crate. Please don't do this. > Don't put any code in your mod.rs and lib.rs files Not very useful. Modern IDEs like VsCode will let you define custom patterns so that you can match `<crate-name>/src/lib.rs` to `crate <crate-name>`. Even without doing this, a lot of the time your first interaction with a crate will be through docs.rs or a manual `cargo doc`, or even just the autocomplete of your IDE. Then, finding the definition of an item is just a matter of asking the IDE (or, grepping for the definition, which is easy to do in Rust since all definitions have a prefix keyword such as `struct`, `enum`, `trait` or `fn`). > Provide a Makefile Please don't do this! In my experience, Makefiles are brittle, push people towards non-portable scripts (since the Makefile uses a non-portable shell by default), `make` is absent by default in certain systems, ... Strongly prefer just working with `cargo` where possible. If not possible, Rust has a design pattern called `cargo xtask`[1] that allows adding cargo subcommands that are specific to your project, by compiling a Rust executable that has a much higher probability to be portable and better documented. If you must, use `cargo xtask`. > Closing words I'm surprised to not find a word about CI workflows, that are in my opinion key to sanely growing a codebase (well in Rust there's no reason not to have them even on smaller repos, but they quickly become a necessity as more code gets added). They will ensure that the project: - has no warning on `main` (allowed locally, error in CI) - is correctly formatted (check format in CI) - has passing tests (check tests in CI, + miri if you have unsafe code, +fuzzer tests) - is linted (clippy) [1]: https://github.com/matklad/cargo-xtask

d profiles, compiler flags, test, documentation or even project in general... are all orthogonal to make 4. It is ad-hoc: as a result of the previous points, the expected functionality of a build system is often re-created in the makefile, but in a non fully standard way (conventions exist, but must be manually enforced and are limited). This results in brittle and difficult to use build systems. > What is an alternative Language-specific package managers, notably Cargo. If using rust, there's also a pattern called xtask[1] that's aiming at providing a standard interface in the form of a binary (since it is rust, it is portable, but most of the other points unfortunately apply). Otherwise, CMake, meson, nix, bazel, buck2 [1]: https://github.com/matklad/cargo-xtask