Put windows deps in (default-included) feature

[jhartzell42]

Due to idiosyncrasies of how cargo resolves dependencies, all the Windows dependencies show up in Cargo.lock files even on Linux -- and in Yocto builds, which is making our build process more difficult. Features do not have the same issue.

There should be a "windows" feature, included by default to avoid breaking existing clients, that can be explicitly disabled if the windows dependencies are not going to be used. This will make building easier on Yocto and other build systems.

I am willing to (and going to) write a PR for this; I'm just adding an issue first for discussion in principle.

[sigmaSd]

Is there an issue about this in cargo repo ?

[jhartzell42]

rust-lang/cargo#1197 is very close.

[jhartzell42]

The fix I have is #767 , which takes my project from not building on Yocto to building on Yocto, I think without hurting anyone else's builds on Windows or Unix.

[jhartzell42]

#767 being merged addresses the issue.

[joshka]

Hey @jhartzell42

I'm looking at @TimonPost's comment on https://github.com/crossterm-rs/crossterm/pull/943/files#r1845623030 about the changes that you made here and trying to understand what the underlying problem was.

The windows deps appearing in the lockfile is intended cargo behavior, as the lockfile doesn't specify which dependencies to use, only which versions of them to use if called for by the manifest. The Cargo.toml file is responsible for choosing which deps to use. The previous configuration without the feature flag correctly gated the windows deps with conditions that only evaluate as true on windows. This works fine on my Mac to not enable the winapi stuff.

I'm curious why the contents of the lock file caused problems in your build process. Is Yocto doing something special?

[joshka]

Digging a bit deeper meta-rust/cargo-bitbake#58 suggests that removing the windows deps from the Yocto side is the correct thing to do, instead of marking the correctly specified deps as optional and behind a feature flag like this. It's possible I'm misunderstanding this in some way...

[joshka]

#948 reverts this change. @jhartzell42 can you please confirm that this doesn't have problems (I think it's the correct thing to do, but would like do check that there's not something I'm missing).

[jhartzell42]

I don't work on the Yocto project anymore and don't have access to it and cannot troubleshoot, unfortunately.

[joshka]

Thanks for the reply. My understanding is that the problem you saw was in generating package config right, i.e. dev / config time problems not a hard fail right? No problem if you can't recall.