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
.rcfile fromNOT MINGWtoWIN32, thus omitting this unnecessary input file for non-Windows platforms. -
Delete the MinGW-specific RC flag
GCC_WINDRES.GCC_WINDRESwas protecting logic that compiles fine with recentwindresversions. 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.exeextension 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.