Theoretically you could do either to manage a project, but it's preference about the model for your project. So if for example you're building something like piston you end up with multiple crate in the same repository because of the size of each of the individual parts: pistoncore-window, pistoncore-input and pistoncore-event_loop. You could have a single crate, with multiple third party dependencies or even just stuff a bloated project into the same crate (Although if it's bloated, think about migrating to separate repositories). Realistically it's just your opinion.
use std::collections::HashMap;
mod fib;
use fib::fibonacci::fb;
fn main() {
let mut map: HashMap<u64, u64> = HashMap::new();
fb(1,&mut map);
}
in Cargo.toml
[package]
name = "learnRust"
version = "0.1.0"
edition = "2018"
[dependencies]
fails with
$ cargo run
Compiling learnRust v0.1.0 (/Users/jpiraguha/dev/rust/packtpub/learnRust)
error[E0658]: imports can only refer to extern crate names passed with `--extern` on stable channel (see issue #53130)
--> src/main.rs:3:5
|
2 | mod fib;
| -------- not an extern crate passed with `--extern`
3 | use fib::fibonacci::fb;
| ^^^
|
note: this import refers to the module defined here
--> src/main.rs:2:1
|
2 | mod fib;
| ^^^^^^^^
error: aborting due to previous error
extern crate is not needed any more since the 2018 edition.
[workspace] is optional. You can use path dependencies without it (but you might need to put it in ../fib so that Cargo doesn't think you're trying to make a workspace).
Libraries often do pub use crate::fibonacci::fb in their lib.rs, so that users of the library don't have to use long module path names, and can use fib::fb instead.
self in that case refers to the current context, which in this case happens to be the crate root, but it could be for example foo::bar::baz crate refers to the project root l, and only of your project ::<foo> refers to the root namespace and you can access anything in any crate
(Where <foo> is replaced with the module you want to go into)
Oh, by the way in rust 1.32 you don't need to use the self keyword to access members in your own module, and are instead automatically included in your namespace.