Tinderbox says Rust ebuild doesn't respect CFLAGS/LDFLAGS

[prophetofxenu]

I have a Rust ebuild I maintain in GURU, walksnail-osd-tool, which I pushed updates to earlier last week.
The next day I received emails about two bugs that had been opened by tinderbox regarding the packages:

Bug 928088 - [guru] media-video/walksnail-osd-tool-0.3.0 does not respect CFLAGS
Bug 928087 - [guru] media-video/walksnail-osd-tool-0.3.0 does not respect LDFLAGS

I'm not a Gentoo expert, a C expert, or a Rust expert, but I am not sure that this fully applies given this is a Rust package. Reading through some of the Rust documentation suggested this could
maybe apply in cases where rustc/cargo is building or linking against C dependencies. I also made a post to the Rust subreddit and the replies I received supported that finding.

My questions are:

• If there are C dependencies, I haven't found a way to tell cargo that the system CFLAGS should be used, or a way to use any specific CFLAGS at all for that matter. I also don't know if there are any
  C dependencies to begin with. There are 400+ crates used by this package and I can't manually inspect all of them. Is there a way to detect these crates, and if so, is it expected that CFLAGS get passed
  to their builds? I am wondering if the tinderbox build just raises this failure if any package fails its heuristic, regardless of what language is used.
  
• For LDFLAGS, these can be specified with

  Code:

  RUSTFLAGS='-Clink-arg=arg1 -Clink-arg=arg2'

  . Obviously this isn't as convenient as something like

  Code:

  RUSTFLAGS="-Clink-args=$LDFLAGS"

  
  but still wouldn't be hard to implement. However I'm wondering, if it's expected that Rust packages will pass LDFLAGS this way, would it be better to include this with the cargo eclass? It seems strange that it
  would be expected for each Rust package to implement this individually. I also ran grep over gentoo and guru and couldn't find anything like the RUSTFLAGS solution I mentioned earlier.
  

I searched the forum for previous posts regarding this issue and was unable to find anything, but apologies if I missed any relevant posts. Also, I'm posting this here because the bug was seemingly created by an automated tool
and I don't know if anyone will respond on the bug, but if this discussion is better left there then I can return. Thanks for your time.

[Ionen]

Fix needed is not as complicated as you think. Portage is not able to correctly detect this on rust-built binaries regardless of pure rust or if they contain C (even if flags were respected, which they typically are with C in crates). It's also unable to automatically know that it should skip the check in this situation.

So, what's missing is just for the ebuild to inform which binaries to skip the check for.

e.g. same as https://github.com/gentoo/gentoo/blob/8a8dedd1/dev-util/maturin/maturin-1.5.1-r1.ebuild#L459 which would fix both bugs (can use ${PN} like there or "usr/bin/walksnail-osd-tool")

Edit:
These QA_* variables are documented in ebuild(5) and are mostly portage-specific. Can use wildcards or regex in there too depending on the variable, albeit a more precise list tend to be preferred if it's not too big (like a single binary).

Go also has the same problem, but the go-module.eclass skips the check for everything (QA_FLAGS_IGNORED=".*") even if there was some non-Go binaries installed (mixed package) for which the check would've been valid.

[prophetofxenu]

Okay, thanks for the info. That should be pretty easy to fix then.

If this is a common issue for Rust ebuilds, would it be worth it then to add a note regarding this to the wiki article on Writing Rust ebuilds?
If so then I'm happy to submit an edit.