Allow users to have 2 different build scripts for Windows depending if rust is the msvc or if it is the gnu build.

[AraHaan]

The issue is that build scripts cannot have the ability to get if the build of rust is msvc or the gnu build for windows so then it fails.

So, with that it would be nice to have build scripts to be able to do it or at least for windows a custom build script for only the msvc build and then a different one for the gnu windows build.

The reason for this is because if you want to import a lib file for a msvc build version because the gnu produces corrupt binaries they would have to have:
__declspec(dllimport)

That is if they are linking to a *lib file made in C or C++ (like the original cpython lib file shipped with the installable python)

The suggestion is to have support for something like this entirely in Cargo.toml:

[package]
name = "crate name here"
version = "version here"
description = "description here"
authors = ["creators here"]
readme = "readme file here"
keywords = [
    "keywords here",
]
homepage = "homepage here"
repository = "repo here"
documentation = "documentation here"
license = "MIT"
exclude = [
    "exclude files here.",
]

[package.x86_64-pc-windows-msvc]
build = "custombuildscripthere.rs"

[package.i686-pc-windows-msvc]
build = "custombuildscripthere.rs"

[package.x86_64-pc-windows-gnu]
build = "custombuildscripthere.rs"

[package.i686-pc-windows-gnu]
build = "custombuildscripthere.rs"

This is so that way Windows would have a better build system for multi platform crates that relies on C or C++ code that has multiple platform implementations like Python's C API for example.

[nagisa]

The issue is that build scripts cannot have the ability to get if the build of rust is msvc or the gnu build for windows so then it fails.

Sure they can. Both rustc-cfg and target_build_utils make exactly this problem a non-problem, but you can also just check the TARGET environment variable and match on whatever, including {i686,x86_64}-pc-windows-{msvc,gnu}.

[AraHaan]

Ah Well I realized the linking issue is basically because of this: #27438

Although I got a better idea why not have some command line an option in cargo build like -dlli (dll import for windows) and just also supply the lib file so that way it can do the dll import using it's symbols?

Think with that it could help somewhat with issues like this?

[retep998]

Solving the dllimport issue shouldn't need any extensions to build scripts. All that is needed is a way to tell rustc which library a given symbol comes from (via a #[link] attribute) and also whether that library is a static library or an import library (via kind=static-nobundle or kind=dylib). Then rustc just needs to put that information to use so it can emit dllimport appropriately. It is mostly already implemented (#37973), it just needs kind=static-nobundle to be added.

[steveklabnik]

This should be filed against https://github.com/rust-lang/cargo/ if there's any outstanding stuff that @retep998 and @nagisa didn't cover. Thanks!