zlib
zlib copied to clipboard
cmake: respect custom RC flags with mingw + delete GCC_WINDRES
Before this patch, zlib.rc
was compiled using a manual command [1] when
using the MinGW toolchain. This method ignores CMAKE_RC_FLAGS
and
offers no other way to pass a custom flag, breaking the build in cases
where a custom windres option is required. E.g. --target=
or -I
on
some platforms and configuration, in particular with llvm-windres.
This patch deletes the special case for MinGW and lets CMake compile the
.rc
file via the standard way used for all WIN32
.
Also:
-
Adjust the condition for dealing with the
.rc
file fromNOT MINGW
toWIN32
, thus omitting this unnecessary input file for non-Windows platforms. -
Delete the MinGW-specific RC flag
GCC_WINDRES
.GCC_WINDRES
was protecting logic that compiles fine with recentwindres
versions. Also, the protected line contained obsolete, 16-bit era keywords that had no effect for a long time. [2] -
Delete the MinGW-specific defaulting logic for
CMAKE_RC_COMPILER
. This is done by CMake automatically, to the more portable default valuewindres
(there is no.exe
extension in cross-toolchains).
[1] dc5a43ebfadb6b775f6e64bfeb5a461c66acb394 [2] https://docs.microsoft.com/windows/win32/menurc/common-resource-attributes
@madler Any love for this PR?
@nmoinvaz Can you enable CI workflows for this PR please?
Hey @vszakats, sorry I don't have access. I'm just a pleb like everybody else here. 😂
Oh, okay, no worries, I do understand the feeling! :)
[ as a shot in the abyss why this PR is not going anywhere, I was about to reinstate the Windows 16-bit bits, if maybe this is a reason for the silence. For the sake of all those Windows 3.11 users out there. One can only guess. ]
Updated the patch to keep support for these legacy bits:
- Windows 16-bit Resource flags.
- MinGW releases that do not support those Windows 16-bit Resource flags.
Please let me know if there is any other concern.
Added a build error log to the top post.