Workspace giving two different behaviors in Rust - rust

I am learning about Cargo workspaces and have set up the following structure:
Top-level:
[package]
name = "workspacer"
version = "0.1.0"
authors = ["ustulation <zzzzzz#gmail.com>"]
[workspace]
members = ["safe_core", "safe_authenticator", "safe_app"]
# If this is removed then each of the sub-projects will have thier own Cargo.lock file
# will build binaries/objects in their own target/ directories. With this present, it's
# always the parent-projects Cargo.lock and target/ directory used. Need to check if this
# is standard behaviour or some bug about to be fixed.
[lib]
crate_type = ["rlib", "cdylib", "staticlib"]
A lib called safe_core which only needs to produce a .rlib
[package]
authors = ["ustulation <zzzzzz#gmail.com>"]
name = "safe_core"
version = "0.1.0"
[dependencies]
maidsafe_utilities = "~0.10.0"
A lib called safe_app which depends on safe_core and needs to produce all 3 .rlib, .a and .so:
[package]
name = "safe_app"
version = "0.1.0"
authors = ["ustulation <zzzzzz#gmail.com>"]
[dependencies]
maidsafe_utilities = "~0.10.0"
safe_core = { path = "../safe_core" }
[lib]
crate_type = ["rlib", "cdylib", "staticlib"]
A lib called safe_authenticator which depends on safe_core and needs to produce all 3 .rlib, .a and .so:
[package]
name = "safe_authenticator"
version = "0.1.0"
authors = ["ustulation <zzzzzz#gmail.com>"]
[dependencies]
safe_core = { path = "../safe_core" }
[lib]
crate_type = ["rlib", "cdylib", "staticlib"]
The tree looks like:
workspacer
├── Cargo.toml
├── safe_app
│   ├── Cargo.toml
│   └── src
│   └── lib.rs
├── safe_authenticator
│   ├── Cargo.toml
│   └── src
│   └── lib.rs
└── safe_core
├── Cargo.toml
└── src
└── lib.rs
If I go to safe_core and build, it creates a target/ folder and Cargo.lock files inside the top level workspacer/, which is good.
If I go to safe_authenticator folder and build that it too uses the same target/ and Cargo.lock files and hence does not recompile safe_core which is what I want too. Same with safe_app.
However if I remove the [lib] section from the top-level workspacer/Cargo.toml, each of the sub-projects start creating their own Cargo.lock files and their own /target directories inside their respective sub-directories. I have mentioned this in the inline comment in the Cargo.toml of workspacer above (the 1st snippet above).
Is this an expected behavior or a bug or am I doing something wrong ?
~$ rustc --version && cargo --version
rustc 1.15.0-nightly (ba872f270 2016-11-17)
cargo 0.15.0-nightly (1877f59 2016-11-16)

After confirming it on latest stable:
~$ rustc --version && cargo --version
rustc 1.13.0 (2c6933acc 2016-11-07)
cargo 0.13.0-nightly (eca9e15 2016-11-01)
It seems to be a bug:
All members of workspace should share the same target directory no
matter what!
A bug report was submitted, and it is solved now.

Related

Local crate not found when trying to update edition via cargo fix

Context:
I have a local C library called 'libmaths' that then uses Bindgen to create a 'libmaths-sys' crate that is locally stored in the same directory as my project.
Issue:
I want to use some of the features in the 2021 edition of Rust and currently my project is built off 2018. I am trying to update the project by following the instructions at:
https://doc.rust-lang.org/cargo/commands/cargo-fix.html
Run cargo fix --edition. Consider also using the --all-features flag if your project has multiple features. You may also want to run cargo
fix --edition multiple times with different --target flags if your
project has platform-specific code gated by cfg attributes.
Modify Cargo.toml to set the edition field to the new edition.
Run your project tests to verify that everything still works. If new
warnings are issued, you may want to consider running cargo fix again
(without the --edition flag) to apply any suggestions given by the
compiler.
To run cargo fix --edition I am told by the compiler to remove the edition="2018" in cargo toml. Following this I receive a compile error stating that libmaths-sys cannot be found. The code compiles and executes normally in 2018 but not without this edition tag.
I can not find anyone with a similar issue, this is my first stackoverflow question so not sure how best to show my code given its a context of a small project.
Error code
error[E0432]: unresolved import `libmaths_sys`
--> src/main.rs:1:5
|
1 | use libmaths_sys::*; // lib.rs in sys crate
| ^^^^^^^^^^^^ maybe a missing crate `libmaths_sys`?
File Structure and general overview of project
.
├── Cargo.lock
├── Cargo.toml
├── libmaths
│   ├── add.c
│   ├── add.h
│   └── subtract.c
├── libmaths-sys
│   ├── build.rs
│   ├── Cargo.lock
│   ├── Cargo.toml
│   ├── src
│   │   └── lib.rs
│   └── wrapper.h
├── README.md
└── src
  ├── lib.rs
  └── main.rs
libmaths contains add.c that returns a + b and subtract.c which returns a - b, with a header add.h directing to both .c files
The Rust code generated by bindgen is attached via lib.rs in the libmath-sys crate which links to the OUT DIR which I have omitted from the tree to save 200 lines of file names.
Try updating edition="2018" to edition="2021"; otherwise it defaults to edition="2015" which requires usage of extern crate.
As #Solomon Ucko directed me to, rustup update held the key.
Running rustup update produced:
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for '1.48-x86_64-unknown-linux-gnu'
info: checking for self-updates
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.59.0 (9d1b2106e 2022-02-23)
1.48-x86_64-unknown-linux-gnu unchanged - rustc 1.48.0 (7eac88abb 2020-11-16)
info: cleaning up downloads & tmp directories
In the end, rustup was using the old 1.48 version and not the installed 1.59 version.
To switch to the newer vesion I ran:
rustup default stable
I then could follow the instructions from the link in the original question to change the edition.

cargo publish "no targets specified in the manifest"

I have a library crate and want to publish it on crates.io.
I created my project with cargo new my_lib --lib.
My project structure looks like this:
my_lib/
├─ src/
│ ├─ lib.rs
├─ examples/
│ ├─ example.rs
├─ benches/
│ ├─ benchmark.rs
├─ .gitignore
├─ Cargo.toml
├─ README.md
├─ config.json
My Cargo.toml looks like this:
[package]
name = "my_lib"
version = "0.1.0"
edition = "2018"
description = "Does cool stuff."
license = "MIT"
readme = "README.md"
repository = "https://git.example.com/my_lib"
homepage = "https://git.example.com/my_lib"
include = ["./config.json"]
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
rand = "0.8.4"
regex = "1"
serde_json = "1.0.64"
When I run cargo publish --dry-run, I get:
error: failed to verify package tarball
Caused by:
failed to parse manifest at `/home/me/my_lib/target/package/my_lib-0.1.0/Cargo.toml`
Caused by:
no targets specified in the manifest
either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present
It tells me to create a src/lib.rs file, but it's there!
If I try to specify the lib.rs file like this:
...
[lib]
path = "src/lib.rs"
...
I get a new error:
error: couldn't read src/lib.rs: No such file or directory (os error 2)
error: aborting due to previous error
error: could not compile `my_lib`
Why won't it let me push my library crate?
When using include, it's necessary to specify every file that is relevant to compilation.
It needs to look like this:
include = [
"src/**/*",
"Cargo.toml",
"config.json"
]
So be sure to include every file that rustc needs to compile and every file that you want to include in your binary.
Credit goes to #Stargateur.

Why is cargo build cache invalidating?

I have a barebones workspace project:
.
├── build-debug.sh
├── Cargo.lock
├── Cargo.toml
├── common
│   ├── Cargo.toml
│   └── src
│   └── lib.rs
├── rs-test.iml
├── server
│   ├── Cargo.toml
│   └── src
│   └── main.rs
└── wui
├── Cargo.toml
└── src
└── lib.rs
The rs files either empty or just an empty main function.
The server and the wui depends on common: common = { path = "../common" }.
The common project has one crates.io dependency with I suppose build script or proc macro dependency.
The build script:
cargo build -p wui --target wasm32-unknown-unknown
cargo build -p server
The problem:
When I rebuild the unchanged project, some wui dependencies are getting invalidated/rebuilt, then the same for server.
Either:
remove the wasm32 target flag
replace the dependency with a simple crate without build time compiled dependencies
It does not rebuild the subprojects anymore.
Is this a cargo bug? What can I do?
It's probably not a cargo bug. What is likely happening here is that your crates.io dependency (you don't mention what it is, which might have been useful) has different dependencies or features depending on the target architecture. Thus, as you alternate between building the WASM target and your host target, stuff is being rebuilt.
Perhaps it would be better in this case to stop using the Cargo workspace and build the server and wui separately; this way you'll have separate target directories for the server and wui, which takes some extra disk space and takes longer for non-incremental compilation, but will prevent you from having to rebuild that stuff all the time as you build both.

How to build multi workspace cargo project in rust

I have multi-workspace Cargo project. It has two workspaces, common and server. common is a lib project and server is a bin project.
The location of the project in Github is here.
Below is the project structure.
.
├── Cargo.toml
├── common
│   ├── Cargo.toml
│   └── src
│   └── lib.rs
├── README.md
└── server
├── Cargo.toml
└── src
└── main.rs
4 directories, 6 files
And the file contents of ./Cargo.toml file is
[package]
name = "multi_module_cargo_project"
version = "0.1.0"
authors = ["rajkumar"]
[workspace]
members = ["common", "server"]
[dependencies]
When I run the command cargo build --all:
error: failed to parse manifest at `/home/rajkumar/Coding/Rust/ProgrammingRust/multi_module_cargo_project/Cargo.toml`
Caused by:
no targets specified in the manifest
either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present
So I added below in Cargo.toml but still couldn't build the project.
[[bin]]
name = "server/src/main.rs"
How can I build the project. What I'm missing?
You included a [package] section in your main Cargo.toml file. This section indicates that you want to build a main package in addition to the packages in the workspace. However, you don't have any source files for the main package, so Cargo complains.
The solution is to simply omit the [package] section, and only include [workspace]. This configures a virtual workspace – a workspace that is only a container for member packages, but does not build a package itself.
See the main Cargo.toml file of Rocket for a real-world example of a virtual workspace, and Tokio for a real-world example of a workspace with a main package.

How do I tell Cargo to build files other than main.rs?

Here is my directory structure:
lowks#lowkster ~/src/rustlang/gettingrusty $ tree .
.
├── Cargo.lock
├── Cargo.toml
├── foo.txt
├── src
│   ├── boolean_example.rs
│   ├── function_goodbye_world.rs
│   ├── listdir.rs
│   ├── looping.rs
│   ├── main.rs
│   ├── pattern_match.rs
│   └── write_to_file.rs
└── target
├── build
├── deps
├── examples
├── gettingrusty
└── native
6 directories, 11 files
When I run 'cargo build', it seems to only build main.rs. How should I change Cargo.toml to build the rest of the files too?
Put other.rs file into bin subfolder of src folder (./src/bin/other.rs). And run cargo build --bin other or cargo run --bin other
The Rust compiler compiles all the files at the same time to build a crate, which is either an executable or a library. To add files to your crate, add mod items to your crate root (here, main.rs) or to other modules:
mod boolean_example;
mod function_goodbye_world;
mod listdir;
mod looping;
mod pattern_match;
mod write_to_file;
To access items defined in another module from your crate root, you must qualify that item with the module name. For example, if you have a function named foo in module looping, you must refer to it as looping::foo.
You can also add use statements to import names in the module's scope. For example, if you add use looping::foo;, then you can just use foo to refer to looping::foo.
For more information, see Separating Modules into Different Files in The Rust Programming Language.
There are a few different types of binaries or targets that cargo recognizes:
binaries
libraries
benchmarks
integration tests
examples
For example, if the file boolean_example.rs is a standalone example that you want to run you can put in inside an examples directory and tell cargo about it like so:
[[example]]
name = "boolean" # examples/boolean.rs
This lets you invoke your example with cargo run --example boolean
Read the cargo book's page on package layout as well to see how these target directories can be structured.
you can include your testing in the main.rs file as following >>
Filename: src/main.rs
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn this_test_will_pass() {
let value = 4;
assert_eq!(4, value);
}
#[test]
fn this_test_will_fail() {
let value = 8;
assert_eq!(5, value);
}
}
Or call them from your tests file.
then run them using test command: cargo test
from filename: lib/tests.rs
mod tests;
tests::run();
in this case main.rs will be built but only tests.rs file will be
executed.
more prove:

Resources