fornwall / rust-script

Run Rust files and expressions as scripts without any setup or compilation step.
https://rust-script.org
Apache License 2.0
1.26k stars 43 forks source link

Specifying build target #23

Closed ethindp closed 1 year ago

ethindp commented 3 years ago

I'm building an OS kernel and use rust-script for some build tasks. However, cargo's config.toml file is still used for the script, and that TOML file contains actions for building parts of the rust standard library (core, alloc, ...). (This is a known issue for cargo.) Is there a way of getting around this? I'm using cargo-make, and I'd explicitly like the build script I use to not be influenced by anything in .cargo/config.toml.

fornwall commented 3 years ago

@ethindp Have you found any way around this?

Does anyone know of a workaround (either to apply manually, or that can be added to rust-script)?

Hecatron commented 3 years ago

I ran into this problem recently, I have a project setup which targets an embedded device with a specific platform. But also a subdirectory inside that with a rust based script I'd like to run unfortunately it looks like cargo searches up the directory tree for .config/config.toml in any of the parent directories which then influences how the script is built (which typically in my case is for the wrong target)

Under windows I had to use the -o option to see the compile fail message

I suspect it might be related to https://github.com/rust-lang/cargo/issues/8643 https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/config.md

chemicstry commented 2 years ago

I also stumbled on this problem. You can solve it by using unstable package.forced-target option (added in https://github.com/rust-lang/cargo/pull/9030) in Cargo.toml instead of setting target in .cargo/config.toml. It's nightly only, but it works.

fornwall commented 1 year ago

But also a subdirectory inside that with a rust based script I'd like to run unfortunately it looks like cargo searches up the directory tree for .config/config.toml in any of the parent directories which then influences how the script is built (which typically in my case is for the wrong target)

The just released version 0.23.0 avoids building the project in the current working directory (instead standing inside of the generated package), so should fix this. Let me know if any problem remains!