`[profile.release]` in config file is ignored

[nastevens]

When building with more verbose logs the following will always be shown:

NOTE: cargo build --verbose --manifest-path /home... <snip>
warning: profiles in config files require `-Z config-profile` command-line option

The reason for this message is that specifying profile.* in a .cargo/config file requires the unstable config-profile flag: https://doc.rust-lang.org/cargo/reference/unstable.html#config-profiles

The result of this is that the debug = true option is not actually being applied, so the binary is not being compiled with full debug information. In the case of Yocto, that's not what we want because we want to build with full debug and then allow Yocto to strip the information off into separate debug files.

I don't immediately see a good way to fix this. Perhaps we could pass the debug level in as a flag using the RUSTFLAGS environment variable, i.e. something like export RUSTFLAGS='-C debuginfo=2' ( debuginfo doc ). But that would definitely need proving out.

[DavidAntliff]

@nastevens As you've suggested, I am trying to get this working with a setting in .cargo/config.toml:

[build]
rustflags = ["-C", "debuginfo=full"]

However, I have found that the Yocto (Langdale) build of the recipe (that uses meta-rust-bin) doesn't seem to pick up the .cargo/config.toml file at all. In fact I can put junk in there and it still builds successfully. Local cargo builds do see and honour it, of course.

Is there something preventing bitbake from seeing the .cargo directory? This happens for both a standard bitbake build, as well as when using devtool modify/build with the -n flag to point devtool at the source directory.

[nastevens]

@DavidAntliff This is actually a bug that is fixed but the issue didn't get updated. What you're seeing is because Yocto builds are isolated so they are as repeatable as possible. So a Yocto build doesn't look at anything on your system or in your home directory, which is why adding that option in that directory had no effect. If you want a custom .cargo/config.toml you'll need to put it in CARGO_HOME as defined by the cargo_bin class. A do_configure:append step is a good place for this. If you run into further issues please open a new issue since I'm going to close this bug.

[nastevens]

This bug doesn't exist anymore since we don't generate a custom .cargo/config to do tool configuration. There is a follow-up issue in #81 that would allow us to do the config we originally were trying to do in .cargo/config, but with environment variables and on stable.

[DavidAntliff]

Oh, I had the .cargo/ directory in my project's root, i.e. as part of the source code tree, not in my home directory. It is seen here by cargo build. I will look into CARGO_HOME though - thank you.