ronnychevalier / cargo-multivers Goto Github PK

Depending on how rustc was built, rustc --print target-cpus can return an error ("Target CPU help is not supported by this LLVM version.").

See https://github.com/rust-lang/rust/blob/ee6533d7408f1447c028025c883a34c904d25ba4/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L365 and rust-lang/rust#104785

We should catch this error and print a friendly error message to the user.

This issue is a continuation of #3. I would like to be able to run all of my tests and benchmarks when using cargo-multivers. I'd also like this to work not just with the built-in tools that cargo has, but also with other tools and libraries such as cargo-criterion, cargo-nextest, etc.

Thank you for making this tool, I fully expect that the performance of my programs will improve significantly, and all without any changes to my code! 😄

I've measured the startup time of Cargo's default "hello world" program on x86_64-unknown-linux-gnu target. If I run cargo multivers and with the default configuration, I'm seeing the startup time of 68ms.

Adding the following lines to Cargo.toml brings it down to 9ms:

[profile.release]
strip = true

This translates into the -C debuginfo compiler flag and instructs the compiler to remove the debug info, which makes up the vast majority of the size of the binary.

I don't think the original debug info would be helpful for an executable that's reconstructed through binary diffing (although I haven't tested it). Perhaps always passing this flag would be a good idea to cut down on binary size and therefore startup time?

If the debug info is still useful in binaries compiled with multivers, I think this trick should not be the default but should be documented in the README.

Compiling 39 versions compressed into a runner
Error: Cargo command failed: The cargo subcommand returned an error.
error: current package believes it's in a workspace when it's not:
current: /home/admin/tmp/surrealdb/target/cargo-multivers/package-runner/Cargo.toml
workspace: /home/admin/tmp/surrealdb/Cargo.toml

this may be fixable by adding target/cargo-multivers/package-runner to the workspace.members array of the manifest located at: /home/admin/tmp/surrealdb/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the workspace.exclude array, or add an empty [workspace] table to the package's manifest.

I got this error 2 times, adding target/cargo-multivers/package-runner to the workspace.members in /home/admin/tmp/surrealdb/Cargo.toml didn't fix the problem. How can I fix this?

It's very tempting to use this with -Zbuild-std, because the standard library contains some algorithms which can be very amenable to instruction selection that depends on features above the baseline.

If I try to run

cargo +nightly multivers -- -Zbuild-std

I don't see any sign of the standard library being rebuilt. Maybe I'm missing it, but that looks like a bug somewhere. Maybe those arguments are dropped? Are they supposed to be passed through to Cargo?

If I try instead:

CARGO_UNSTABLE_BUILD_STD=std cargo +nightly multivers

The build crashes at the last phase with a bunch of errors like this:

error[E0152]: duplicate lang item in crate `core`: `sized`.
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /tmp/scratch/target/cargo-multivers/x86_64-unknown-linux-gnu/release/deps/libcore-c40ee5b690d29378.rlib, /tmp/scratch/target/cargo-multivers/x86_64-unknown-linux-gnu/release/deps/libcore-c40ee5b690d29378.rmeta
  = note: second definition in `core` loaded from /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-632ae0f28c5e55ff.rlib

This happens when building with -Cpanic=abort but when there's no panic_abort crate in the sysroot. It's rather surprising that I was quietly opted into aborting panics; but if a user knows about this situation it's not hard to pass

CARGO_UNSTABLE_BUILD_STD=std,panic_abort cargo +nightly multivers

... but if they don't, this just looks like a bug in cargo-multivers.

Calling cargo multivers blindly without limiting the set of CPUs will lead to a long build time for a big project (several hours).

To limit this, we can provide "good defaults" for some architectures:

• x86-64: Use the microarchitecture levels x86-64,x86-64-v2,x86-64-v3,x86-64-v4. It will generate 4 builds of the project instead of 39 which will cover various sets of extensions while limiting the build time.

To see the set of features enabled for a given CPU and a given target: rustc --print cfg -C target-cpu=x86-64-v4 --target x86_64-pc-windows-msvc