Linking errors with lime rebuild winrt

[tobil4sk]

Not sure if this is still considered supported, but it seems lime rebuild winrt does not build properly.

This patch resolves some of them:

diff --git a/project/Build.xml b/project/Build.xml
index d6f0d7c..698f501 100755
--- a/project/Build.xml
+++ b/project/Build.xml
@@ -105,6 +105,7 @@

                <section if="LIME_FREETYPE">

+                       <compilerflag value="-I${NATIVE_TOOLKIT_PATH}/custom/freetype/include/" />
                        <compilerflag value="-I${NATIVE_TOOLKIT_PATH}/freetype/include" />
                        <compilerflag value="-DLIME_FREETYPE" />

@@ -440,6 +441,8 @@
                                <lib name="RuntimeObject.lib" if="winrt" />
                                <lib name="Xinput.lib" if="winrt" />
                                <lib name="DXGI.lib" if="winrt" />
+                               <lib name="Synchronization.lib" if="winrt" />
+                               <lib name="Mmdevapi.lib" if="winrt" />

                                <lib name="-libpath:../templates/bin/hl/${BINDIR}" if="LIME_HASHLINK" />
                                <lib name="libhl.lib" if="LIME_HASHLINK" />
diff --git a/project/lib/sdl-files.xml b/project/lib/sdl-files.xml
index c9c5011..19d84e3 100755
--- a/project/lib/sdl-files.xml
+++ b/project/lib/sdl-files.xml
@@ -476,15 +476,16 @@
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/haptic/windows/SDL_dinputhaptic.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/haptic/windows/SDL_windowshaptic.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/haptic/windows/SDL_xinputhaptic.c" />
-            <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/hidapi/windows/hid.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/joystick/windows/SDL_dinputjoystick.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/joystick/windows/SDL_windowsjoystick.c" />
+            <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/joystick/windows/SDL_windows_gaming_input.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/joystick/windows/SDL_xinputjoystick.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/loadso/windows/SDL_sysloadso.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/render/direct3d11/SDL_render_d3d11.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/render/direct3d12/SDL_render_d3d12.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/render/SDL_d3dmath.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/thread/generic/SDL_syscond.c" />
+            <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/thread/windows/SDL_syscond_cv.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/thread/windows/SDL_sysmutex.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/thread/windows/SDL_syssem.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/thread/windows/SDL_systhread.c" />
@@ -499,6 +500,7 @@
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/misc/windows/SDL_sysurl.c" />
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/power/windows/SDL_syspower.c" />
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/render/direct3d/SDL_render_d3d.c" />
+                <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/hidapi/windows/hid.c" />
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/video/windows/SDL_windowsclipboard.c" />
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/video/windows/SDL_windowsevents.c" />
                 <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/video/windows/SDL_windowsframebuffer.c" />
@@ -524,6 +526,7 @@
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/core/winrt/SDL_winrtapp_direct3d.cpp" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/core/winrt/SDL_winrtapp_xaml.cpp" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/filesystem/winrt/SDL_sysfilesystem.cpp" />
+            <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/haptic/dummy/SDL_syshaptic.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/locale/winrt/SDL_syslocale.c" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/misc/winrt/SDL_sysurl.cpp" />
             <file name="${NATIVE_TOOLKIT_PATH}/sdl/src/power/winrt/SDL_syspower.cpp" />

However, then I still get a cairo error:

Link: obj/lib/lime.ndll
   Creating library obj\lib\lime.lib and object obj\lib\lime.exp
f6b9188d_cairo-misc.obj : error LNK2019: unresolved external symbol _CreateFileW referenced in function __cairo_tmpfile
obj\lib\lime.ndll : fatal error LNK1120: 1 unresolved externals

CreateFileW is only available for windows desktop apps. I suppose this would have to be handled upstream in cairo, not sure if that project has winrt support.

[tobil4sk]

We could try to upstream a cairo patch, but the current winrt build is based on c++/cx which was since replaced with c++/winrt (which hxcpp doesn't support yet) and even c++/winrt uwp apps have been replaced with the windows app sdk: https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/migrate-to-windows-app-sdk-ovw

It probably doesn't make sense to try to upstream c++/cx code to cairo given it is a legacy technology. Maybe c++/winrt would still be more reasonable, but it still won't build because SDL2 doesn't have c++/winrt support and SDL3 has removed UWP support altogether: libsdl-org/SDL#6870.

Maybe it would be better to follow SDL's example and deprecate winrt (which is broken already anyway) and remove it with Lime 9. (Unless SDL's decision is reversed, which was has been discussed libsdl-org/SDL#10724 (comment)).

[joshtynjala]

Maybe it would be better to follow SDL's example and deprecate winrt (which is broken already anyway) and remove it with Lime 9.

I'm okay with this.

[tobil4sk]

Another idea I've come up with is that we can still compile some c++/cx files at the same time as c++/winrt files, as long as hxcpp is updated to support this.

So maybe we can restore a working UWP build for lime 8. Since SDL3 is planned for lime 9, we will still have to remove it there. However, at least that way users who want UWP would still have the option to stay on lime 8. It seems there are still some usecases for UWP with certain methods of deploying to console, e.g. as mentioned in #2050.