Open Phidelux opened 1 year ago
I have the same issue when using cargo-bitbake
on a rocket based project.
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.
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.
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
.
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 withcargo tree
these dependencies are not included, as my currently configured default toolchain isstable-x86_64-unknown-linux-gnu
and I have to explicitly ask for a windows target usingcargo 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.