Skip to content

[profile.release] in config file is ignored #64

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nastevens opened this issue Feb 1, 2020 · 4 comments
Closed

[profile.release] in config file is ignored #64

nastevens opened this issue Feb 1, 2020 · 4 comments
Labels

Comments

@nastevens
Copy link
Member

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
Copy link

DavidAntliff commented Feb 28, 2024

@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 nastevens added the bug label Feb 28, 2024
@nastevens
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link

DavidAntliff commented Feb 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants