Fix compilation with mingw

[Rookfighter]

The buildfiles currently contain code for building with mingw, but the build fails for some reason. Investigate on the root cause and fix the compilation.

[Swat-SomeBug]

I had a quick look into the issue:

1. Package libimgui-platform-win32 needs to link with dwmapi.lib and gdi.lib which for some reason is not a problem for msvc. Nonetheless, I'm working on a PR to basically do this (still WIP):

if($cxx.target.system == 'mingw32')
  cxx.libs += -ldwmapi -lgdi32
else
  cxx.libs += dwmapi.lib gdi32.lib

2. There seems to be an issue compiling libimgui-render-dx[10,11,12] with mingw. Note libimgui-render-dx9 compiles just fine.
   The compilation error comes from mingw's handling of -fpreprocessed and -fdirectives-only flags (which build2 uses to extract header information) compared to normal compilation into an object file.
   I tested a manual compilation and it works fine. With the above options, I get the following error:

..\libimgui-render-dx10\imgui\imgui_impl_dx10.dll.o.ii:150889:13: error: unterminated string literal

The error line number is not super useful because there is seems to be some quote missed somewhere else. I'm suspecting, windows path style vs linux path styles. Cannot really say at the moment.
The error itself happens when manually compiling with mingw with -fpreprocessed -fdirectives-only options and is little to do with build2. It so happens that build2 is "pre-compiling" the file which is why builds don't go through.

@boris-kolpackov To me this seems like a bug in mingw. But I believe gcc was having a similar issue on linux sometime ago. Do you have any experience with this?
For reference, I currently have the following version of mingw on my local machine. I have not tested with other versions.

$> C:\mingw64\bin\g++ --version
g++ (x86_64-win32-seh-rev3, Built by MinGW-W64 project) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Edit:

• Name of packages *directx -> dx.
• Library name gdi -> gdi32

[Swat-SomeBug]

Update:
The issue seems to be with mingw version. mingw on my Fedora box seems to compile dx[9,10,11].

$> /usr/bin/x86_64-w64-mingw32-c++ --version
x86_64-w64-mingw32-c++ (GCC) 11.2.1 20211019 (Fedora MinGW 11.2.1-5.fc36)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm still having other issues with dx12 on Fedora.
Nonetheless, mingw32-11 seems to work ok while something broke in mingw-12.

[Swat-SomeBug]

Update 2:
I believe I have figured out what's happening with libimgui-render-dx12.

• Basically d3d12.h should provide an API for both VERSIONED and non-VERSIONED signatures of D3D12SerializeRootSignature as per official documentation from MS.
• The VERSIONED APIs supersede the non-VERSIONED APIs as explicitly mentioned.
• Now mingw has it's own directx headers that provide only the VERSIONED APIs. This is true for both mingw-11 and mingw-12.
• Upstream however, relies on the non-VERSIONED APIs which causes compilation to fail.

I locally edited upstream code to use VERSIONED APIs and compilation goes through successfully.

The app itself is not running via wine for me and running on windows requires a downgrade of mingw.
Will setup tomorrow and update.

[boris-kolpackov]

The error itself happens when manually compiling with mingw with -fpreprocessed -fdirectives-only options and is little to do with build2.

I am pretty sure this is GCC bug #84583. It only manifests itself when compiling natively on Windows which I believe is why you don't see the same issue when cross-compiling from Fedora.

I think in this light (and due to other issues), it's perfectly reasonable to postpone MinGW support for imgui.