Use a manifest on Windows for UTF8 handling #1752
Conversation
vrabaud
force-pushed
the
utf8_manifest
branch
from
f37635b to
b525291
Compare
vrabaud
force-pushed
the
utf8_manifest
branch
3 times, most recently
from
7afca00 to
e9a5c7d
Compare
vrabaud
force-pushed
the
utf8_manifest
branch
from
e9a5c7d to
c22be08
Compare
| add_custom_command( | ||
| TARGET ${PROG} | ||
| POST_BUILD | ||
| COMMAND "mt.exe" -manifest \"${CMAKE_SOURCE_DIR}\\src\\utf8.manifest\" |
There was a problem hiding this comment.
I don't think this can work on MinGW, there is no mt.exe...
There was a problem hiding this comment.
Can MINGW access the Windows SDK and therefore "mt.exe"?
It seems adding the manifest as source (or at least the .rc) works, cf https://doc.magnum.graphics/magnum/platforms-windows.html . Can you confirm this is the way to go? I have no experience with manifest files, @wantehchang just found this cleaner solution for handling UTF8.
There was a problem hiding this comment.
I don't think one can assume MinGW users/devs will have access to the Windows SDK.
I might be completely wrong here, but perhaps a conversation is to be had w/ the MinGW (or is it Cygwin?) project to ship a pre-built UTF8 object manifest that can be statically linked in then, like the existing ("regular"?) one?
There was a problem hiding this comment.
Furthermore, the https://cygwin.com/git/?p=cygwin-apps/windows-default-manifest.git;a=tree also seems to wrap that default manifest into a .rc file (that's then compiled to an object), and resource files can be dealt with w/o a problem in MinGW toolchains (windres is shipped, so just add them as another source file). Maybe that could indeed be a temporary workaround?
With a gotcha from your magnum link:
A downside is that MinGW is not able to merge information from multiple manifests like the MSVC toolchain can.
So a complete UTF8 .rc needs to be constructed it seems?
There was a problem hiding this comment.
Miloš: Thank you very much for the research.
The UTF-8 support for libavif is simpler than the UTF-8 support for RStudio, because the libavif library itself has only one function, avifIOCreateFileReader(), that takes a filename input parameter, and that function faithfully passes filename to fopen() with no processing. So we can document that the libavif library honors the code pages selected by the application, and we just need to solve the UTF-8 support problem for the three command-line programs, avifdec, avifenc, and are_images_equal. And it is fine to solve the UTF-8 support problem on Windows 10 and later only so that we can use the simple solution of the manifest file.
| target_link_libraries(${PROG} avif_apps) | ||
| if(WIN32) | ||
| # Add a manifest file to deal with UTF8. | ||
| if(CMAKE_C_COMPILER_ID MATCHES "MSVC") |
|
Go with the cleaner #1900 |
This first reverts #1693 (except for test_cmd.sh) and applies a manifest on Windows platforms.
CMake handles manifests as source files on Windows but most likely only for MSVC (cf https://cmake.org/cmake/help/v3.4/release/3.4.html#other).