Issue when building a crate with both bin and lib targets.

[MaxMahem]

I love the crate, but I did run into one issue, though. I'm not sure how much this is even something that can be solved. But when converting my bin crate over to also have a lib target (so I could do some integrated testing), I started having problems with my embedded resources not embedding properly. Part of it I think was a bug in the version you yanked (at least, upgrading to 1.23 fixed it). But after that the issue of my items not being embedded remained.

After some trial and error, I managed to fix it.

// force rustc to link to our windows embedded resource.
#[link(name = "resource", kind = "dylib")]
unsafe extern "C" {}

I'm a bit confused as to why it works, or why the resources were pruned to begin with? I didn't even think/know resources like this could get pruned.

Anyways, like I said, between Rust only having one build script per crate and whatever Rustc is doing (and what I might still be doing wrong), I'm not even sure there is anything to be fixed here. But I thought it might be worth letting you know.

[BenjaminRi]

• I yanked 0.1.24 due to a bug caused by bumping the TOML dependency, which caused values in package.metadata.winresource to be silently ignored (#41). This is fully fixed starting with 0.1.26.
• I yanked 0.1.25 due to the following issue #40 which is not fully understood (I cannot afford to keep a version with a build failure around, since that would break things downstream for a bunch of people)

The first change is certainly unrelated, the second one (#40) is likely related to your issue, yes.

You say

at least, upgrading to 1.23 fixed it

but I did not yank 0.1.23, nor does this version contain a fix for this problem. So, I do not understand that part of the bug report. Did you mean 0.1.25?

Long story short: Understanding #40 is a blocker for fixing this. In addition to that, the unit tests must be expanded a lot to avoid any breakage for downstream users. Because there are so many ways to use this target (every platform, cross-compilation, etc.) any change has a high probability to blow up somewhere when I change anything.