Then from the src/api/server.rs I need to use the parsing module and this is what I can’t understand how.
when the server.rs is located in src/server.rs - can refer to the module by mod parsing (and the appropriate use-s)
when the server.rs is located in src/api/server.rs - the parsing module cannot be referred to anymore because:
// error[E0583]: file not found for module `parsing`
// --> src/api/server.rs:21:5
// 21 | mod parsing;
// | ^^^^^^^
// = help: name the file either parsing.rs or parsing/mod.rs inside the directory "src/api"
So my question is how do I get hold of sibling modules in relation to the api?
It’s not strictly necessary to put it under src/ (although no reason to deviate), but Cargo automatically knows that src/bin/... contains binaries. Otherwise, you can put them elsewhere and note them with the [[bin]] section, as in the OP.
The typical project layout is detailed in the Cargo reference.
If the binary is in the root of src/, the binary itself is the crate root module and declaring mod parser; in it is the standard way of telling rustc about the child modules contained in the crate. If you move the binary to a subdirectory, then I don’t think module resolution, from the root module, can go upwards in the directory structure.
But in general, defining binaries that are essentially consumers of your library crate has some benefits. Not only is the separation clearer (IMO), but it also gives you the perspective of your would-be lib consumers (even if none today, perhaps some in the future) and so you can see how it feels to work with your lib “externally”.
Is it correct to say that when I point [[bin]]'s path to the root (src) then the whole codebase is a crate.
And if there are 2 bins then the those get compiled twice as 2 separate crates that just happen to share the same codebase?