Fix Meson naming convention

[kleisauke]

This PR fixes two issues when using --meson-paths.

• Ensure import libraries under MinGW are named libfoo.dll.a (44e96dc).

  @@ -4,5 +4,5 @@
        Copying /tmp/rav1e/x86_64-pc-windows-gnullvm/release/rav1e.h to /usr/x86_64-w64-mingw32/include/rav1e/rav1e.h
     Installing shared library
        Copying /tmp/rav1e/x86_64-pc-windows-gnullvm/release/rav1e.dll to /usr/x86_64-w64-mingw32/bin/librav1e.dll
  -     Copying /tmp/rav1e/x86_64-pc-windows-gnullvm/release/rav1e.dll.a to /usr/x86_64-w64-mingw32/lib/rav1e.lib
  +     Copying /tmp/rav1e/x86_64-pc-windows-gnullvm/release/librav1e.dll.a to /usr/x86_64-w64-mingw32/lib/librav1e.dll.a
        Copying /tmp/rav1e/x86_64-pc-windows-gnullvm/release/rav1e.def to /usr/x86_64-w64-mingw32/lib/rav1e.def

• Shared libraries under MSVC are always in the form foo.dll (9cf2de8).

  @@ -3,7 +3,7 @@
     Installing header file
        Copying C:\Users\kleisauke\rav1e\target\x86_64-pc-windows-msvc\release\rav1e.h to C:\include\rav1e\rav1e.h
     Installing shared library
  -     Copying C:\Users\kleisauke\rav1e\target\x86_64-pc-windows-msvc\release\rav1e.dll to C:\bin\librav1e.dll
  +     Copying C:\Users\kleisauke\rav1e\target\x86_64-pc-windows-msvc\release\rav1e.dll to C:\bin\rav1e.dll
        Copying C:\Users\kleisauke\rav1e\target\x86_64-pc-windows-msvc\release\rav1e.lib to C:\lib\rav1e.lib
        Copying C:\Users\kleisauke\rav1e\target\x86_64-pc-windows-msvc\release\rav1e.def to C:\lib\rav1e.def
     Installing debugging information

/cc @amyspark

As an aside, I've encountered the same issue as #426 with the x86_64-pc-windows-gnullvm target. It looks like -Wl,--output-def here:

cargo-c/src/target.rs

Lines 112 to 118 in c4e6c08

	} else if os == "windows" && env == "gnu" {
	// This is only set up to work on GNU toolchain versions of Rust
	lines.push(format!(
	"-Wl,--output-def,{}",
	target_dir.join(format!("{lib_name}.def")).display()
	));
	}

also generates a .def file with a missing library name, at least on LLVM (I haven't checked Binutils):
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.6/lld/COFF/MinGW.cpp#L173-L192

Perhaps we could somehow allow implib to override the import library name?:
https://github.com/messense/implib-rs/blob/v0.3.3/src/lib.rs#L109-L112

[amyspark]

This bit is not entirely correct, under the Meson convention import libs are lib but also static libs are changed to a. https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa

[kleisauke]

Static libs behavior is controlled by:

cargo-c/src/build_targets.rs

Lines 118 to 129 in 5a92c3f

	pub fn static_output_file_name(&self) -> Option<OsString> {
	match self.lib_type() {
	LibType::Windows => {
	if self.static_lib.is_some() && self.use_meson_naming_convention {
	Some(format!("lib{}.a", self.name).into())
	} else {
	Some(self.static_lib.as_ref()?.file_name()?.to_owned())
	}
	}
	_ => Some(self.static_lib.as_ref()?.file_name()?.to_owned()),
	}
	}

The shared_lib, static_lib or pdb declarations cannot be modified here, as they also define which library is copied from Rust. Consequently, this logic must always align with:
https://github.com/rust-lang/rust/blob/1.84.0/compiler/rustc_target/src/spec/base/windows_msvc.rs#L11-L15

[kleisauke]

PR #433 will fix the CI failures.

As an aside, I've encountered the same issue as #426 with the x86_64-pc-windows-gnullvm target. It looks like -Wl,--output-def here:

cargo-c/src/target.rs

Lines 112 to 118 in c4e6c08

	} else if os == "windows" && env == "gnu" {
	// This is only set up to work on GNU toolchain versions of Rust
	lines.push(format!(
	"-Wl,--output-def,{}",
	target_dir.join(format!("{lib_name}.def")).display()
	));
	}

also generates a .def file with a missing library name, at least on LLVM (I haven't checked Binutils):
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.6/lld/COFF/MinGW.cpp#L173-L192
Perhaps we could somehow allow implib to override the import library name?: https://github.com/messense/implib-rs/blob/v0.3.3/src/lib.rs#L109-L112

Work-in-progress commit kleisauke@6ad3303 seems to fix this.

[lu-zero]

If you have time during the weekend I'd fold your fixes in the next release.

[lu-zero]

Thank you I defer to @amyspark for the review since I do not know enough of windows to be sure :)