benjaminri / winresource Goto Github PK

rustc version: rustc 1.66.1 (90743e729 2023-01-10)
winresource version: 0.1.14

I get the following error when I cross compile from Debian 11:
"error: the linking modifiers +bundle and +whole-archive are not compatible with each other when generating rlibs"

Changing

println!("cargo:rustc-link-lib=static:-bundle,+whole-archive=resource");

resolves this issue. But i don't know if this breaks builds with previous rustc versions...

Example build.rs:

// build.rs

fn main() {
    if std::env::var("CARGO_CFG_TARGET_OS").unwrap() == "windows"
        && std::env::var("PROFILE").unwrap() == "release"
    {
        let mut res = winresource::WindowsResource::new();

        res.set_icon("assets/favicon.ico")
            .set("ProductName", "some name")
            .set("CompanyName", "some company")
            .set("ProductVersion", "0.1.0")
            .set("FileVersion", "0.1.0.0")
            .set("FileDescription", "some description")
            .set("LegalCopyright", "Copyright © Example")
            .compile()
            .unwrap();
    }
}

Hi, and thanks for this great library!

I have added a PR to include setup instructions and sample code.

Track issue mxre/winres#44

I am using cargo-xwin to cross-compile my project from Linux using the MSVC toolchain.

I was able to make it work with a symlink for rc.exe to the LLVM provided tools llvm-rc-14, but that feels kind of hacky :)
I would like to make a PR but I am not sure what is the best approach.

Track issue mxre/winres#28 which was closed without action (so it's still open, technically).

Track issue mxre/winres#38

If someone has a cargo.toml that has multiple output binaries, like this:

[[bin]]
name = "foo"
path = "bin/foo.rs"

[[bin]]
name = "bar"
path = "bin/bar.rs"

[[bin]]
name = "buzz"
path = "bin/buzz.rs"

Then there isn't a way to tell win resource which icon to apply to which binary, short of making a new cargo project.
Is this impossible due to build.rs limitations, or can it be accomplished?

https://stackoverflow.com/questions/15495613/correct-usage-of-the-versioninfo-resource

It is up for debate whether we should put the application name or the description (like I have done in 3cf2f62) into that field . See also: mxre/winres#43

Track issue mxre/winres#25

If you just use the crate as described in the README.md, the manifest will also end up in the library crate and linked to crates depending on this crate. This should be documented and avoided if at all possible, as the manifest is often only meant for the binary, or for a cdylib if built and so on, but not for the rlib, or crates that depend on the crate using this crate.

Using #[cfg(target_os = "windows")] in build.rs (and its dependencies like lib.rs of this crate) may not work as expected because build.rs is executed on the host. This means that target_os is always equal to host_os when compiling build.rs. E.g. if we use rustc on Linux and want to cross-compile binaries that run on Windows, target_os in build.rs is "linux".

Instead, we have to use environment variables like CARGO_CFG_TARGET_OS which are set to the actual build target properties.

This may also apply to other definitions like cfg!(target_arch = "x86_64"), etc.