Do no include windows apis

[Phidelux]

I am trying to generate a bitbake recipe without any windows dependencies.

The application I am building depends on log4rs, which depends on the winapi crate. However, this dependency is only enabled when building for windows systems as it is placed in the [target.'cfg(windows)'.dependencies] section in the log4rs Cargo.toml. Thus, I would expect that these dependencies are not included in the generated bitbake recipe. When checking the dependency tree with cargo tree these dependencies are not included, as my currently configured default toolchain is stable-x86_64-unknown-linux-gnu and I have to explicitly ask for a windows target using cargo tree --target x86_64-uwp-windows-gnu to see the windows dependencies in the graph. Moving all dependencies into a [target.'cfg(linux)'.dependencies] does no fix this issues.

Why are windows dependencies included at all in the bitbake recipes, as "The Yocto Project (YP) is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture."

Removing the windows dependencies from the generated bitbake recipe works perfectly fine, however there might be dependencies which are not that easy to identify as windows dependencies.

Is there a quick fix for this issue and is this considered expected behavior?

Thanks.

[be-neth]

I have the same issue when using cargo-bitbake on a rocket based project.

[eivindbergem]

It seems that the dependencies produced by cargo bitbake corresponds to the output of cargo tree --target all. I had a look at the code, and it shouldn't be too difficult to fix this by limiting the dependency resolver to a set of valid targets.

[eivindbergem]

I had a try at this, and it is trickier than I expected. I thought I could use cargo::ops::resolve_ws_with_opts and use the requested_targets argument to only get packages for the specified targets, but I get the windows dependencies nonetheless.

I had a look at how cargo tree does it, and it is quite convoluted. I'll try some more, but I might just throw in the towel before I sink too much time into this.

[eivindbergem]

cargo tree does a lot of processing, but at the moment the API is not fully exposed. cargo::ops::tree::build_and_print builds and prints in one go.

The best option would be to expose this in cargo, to avoid duplicating the work in cargo bitbake.