Okay, so MinGW-w64 on Azure Pipelines is a non-starter. Let's find out what the macOS SDKs are *actually* called.

azure-pipelines.yml

@@ -4,60 +4,31 @@ variables:
   releaseExamples: 'controlgallery cpp-multithread datetime drawtext histogram tester timer'
 
 jobs:
-- job: windows_386_mingw_static
+- job: darwin_amd64_1014sdk_shared
-  displayName: 'Windows 386 MinGW-w64 Static'
+  displayName: 'Darwin amd64 10.14 SDK Shared'
   pool:
-    vmImage: 'vs2017-win2016'
+    vmImage: 'macos-10.13'
   workspace:
     clean: all
   steps:
   - template: azure-pipelines/setup-python3.yml
   - template: azure-pipelines/install-latest-meson.yml
-  - template: azure-pipelines/windows-install-ninja.yml
+  - template: azure-pipelines/darwin-install-ninja.yml
-  - template: azure-pipelines/windows-setup-mingw.yml
+  - script: |
-    parameters:
+      xcodebuild -showsdks
-      which: mingw32
+      exit 1
+    displayName: "Help"
   - template: azure-pipelines/configure.yml
     parameters:
-      defaultLibrary: static
+      beforeConfigure: export SDKROOT=$(xcodebuild -version -sdk macosx10.14 Path)
+      defaultLibrary: shared
   - template: azure-pipelines/build.yml
     parameters:
-      afterBuild: dir build\meson-out
+      beforeBuild: export SDKROOT=$(xcodebuild -version -sdk macosx10.14 Path)
-#      afterBuild: ren build\meson-out\libui.a libui.lib
+  - template: azure-pipelines/darwinunix-artifacts.yml
-#  - template: azure-pipelines/windows-artifacts.yml
-#    parameters:
-#      os: windows
-#      arch: 386
-#      toolchain: mingw
-#      libtype: static
-#      libfiles: libui.lib
-#      osHeader: ui_windows.h
-
-- job: windows_amd64_mingw_static
-  displayName: 'Windows amd64 MinGW-w64 Static'
-  pool:
-    vmImage: 'vs2017-win2016'
-  workspace:
-    clean: all
-  steps:
-  - template: azure-pipelines/setup-python3.yml
-  - template: azure-pipelines/install-latest-meson.yml
-  - template: azure-pipelines/windows-install-ninja.yml
-  - template: azure-pipelines/windows-setup-mingw.yml
     parameters:
-      which: mingw64
+      os: darwin
-  - template: azure-pipelines/configure.yml
+      arch: amd64
-    parameters:
+      libtype: shared
-      defaultLibrary: static
+      libfiles: libui.A.dylib
-  - template: azure-pipelines/build.yml
+      osHeader: ui_darwin.h
-    parameters:
-      afterBuild: dir build\meson-out
-#      afterBuild: ren build\meson-out\libui.a libui.lib
-#  - template: azure-pipelines/windows-artifacts.yml
-#    parameters:
-#      os: windows
-#      arch: amd64
-#      toolchain: mingw
-#      libtype: static
-#      libfiles: libui.lib
-#      osHeader: ui_windows.h

azure-pipelines/windows-setup-mingw.yml

@@ -1,18 +0,0 @@
-# 7 april 2019
-
-parameters:
-  which: 'must-be-specified'
-
-steps:
-- powershell: |
-    Set-PSDebug -Trace 2
-    ls "$env:ChocolateyInstall\lib\mingw\tools\install"
-    where.exe mingw32-make.exe | Write-Host
-    where.exe gcc.exe | Write-Host
-    $chocopath = where.exe choco.exe | Get-Item
-    # apparently they didn't think to add this functionality from the start (multiple joins was only added in PowerShell 6 and Azure Pipelines is using 5.x), and the direct-CLR approach actually behaves differently (and I would need to check which version of .net Azure Pipelines is using anyway, since our use case isn't one of those cases where it behaves differently)
-    $chocopath = Join-Path -Path $chocopath.Directory -ChildPath "install" | Join-Path -ChildPath "${{ parameters.which }}" | Join-Path -ChildPath "bin"
-    ls $chocopath
-    Write-Error "##vso[task.prependpath]$chocopath"
-    exit 1
-  displayName: 'Set Up MinGW-w64'