Custom runner without specifying target about cargo HOT 5 CLOSED

@weihanglo That works, but actually does not solve my issue specifically - but I think it's because the runner script is not what was causing my issue in the first place. I effectively have the following setup:

.
└── workspace_root/
    ├── .cargo/
    │   └── config.toml
    ├── bin_crate/
    │   ├── .cargo/
    │   │   └── config.toml
    │   ├── src/
    │   │   └── main.rs
    │   └── Cargo.toml
    ├── lib_crate/
    │   ├── src/
    │   │   └── lib.rs
    │   └── Cargo.toml
    ├── scripts/
    │   └── run.sh
    └── Cargo.toml

In my above structure, the bin crate is a #![no_std] crate with the following in the .cargo/config.toml:

[build]
target = "x86_64-unknown-uefi"

[unstable]
build-std = ["core", "compiler_builtins"]
build-std-features = ["compiler-builtins-mem"]

[target.x86_64-unknown-uefi]
runner = "../scripts/run.sh"

The lib crate is just a regular crate, no special config except for a #![cfg_attr(not(test), no_std)] annotation in the lib.rs.

I'm finding that no matter what kind of config I use in the workspace root, I cannot get it to build the project from there. I'm getting errors from other external crates failing to compile, unless the workspace config exactly matches the bin config - but then my issue with the lib crate not being no_std pops up again.

Ideally, what I want is for cargo run in the workspace root to be identical to cd bin_crate && cargo run, where bin_crate is either the only bin crate, or one specified as the default in the workspace. That is how I am currently running it and it works for now.

I guess maybe a default runner is not the goal then - as it would seem runners first build the crate, and then pass the crate path as an arg to the runner. If I could specify a custom build command as well, that would be ideal. Then I could wire something up that fits my use case.

Something like this maybe:

[build]
build_command = "cd bin_crate && cargo build && cd .."

Or provide some other kind of configuration option, specifically for workspaces even, that enables building and running from the default crate, honoring its configuration.

from cargo.

Does cargo run --config "target.'cfg(all())'.runner=['echo']" work for you?

Or within .cargo/config.toml:

[target.'cfg(all())']
runner = ['echo']

You could also use --config <path-to-a-config-toml-file> flag to do a one-off config loading.

from cargo.

Thanks for sharing! I can see where you're from. Cargo's configuration discovery always starts from the current working directory, regardless what you're building. This umm… feature, is not going to change anytime soon. However, we have some alternative for this.

• Command-line overrides. Let's say you have a .cargo/no-std.config.toml at workspace root. You can read it via --config <path>. Since it's not named .cargo/config.toml, it'll never be picked up by Cargo automatically.
• You can combine --config with user-defined [alias], such as

  [alias]
  build-bin = "build -p bin_crate --config .cargo/bin-crate.config.toml"

  So that can save some keystrokes for you.
• There is an unstable -C <dir> flag to switch to a directory. Cargo will start the config discovery from the given <dir>.
• Your proposed solution looks pretty much like #6575, which proposes to extend alias to allow arbitrary commands.
• There is a plan of moving some project-specific config to manifest (Cargo.toml). This is pretty relevant to this issue.

Granted, things above are not all “alternatives”. Some of them are still in design stages. Yet I think we can instead track those issues and close this one. Do you have any specific request that is not covered by aforementioned issues?

from cargo.

@weihanglo Fair enough! Thanks for your help, and that alias solution and proposal sounds great, it aligns pretty much with what I'm doing anyway which is running a custom script instead of cargo run. The alias solution is cleaner, not sure how I missed that in my research.

from cargo.

Thanks! Closing in favor of #6575. Feel free to comment there or elsewhere :)

from cargo.