From e1d9215cece2519099ac0c7a773ddbefef1e05a9 Mon Sep 17 00:00:00 2001
From: cancel <cancel@cancel.fm>
Date: Wed, 29 Jan 2020 02:31:25 +0900
Subject: [PATCH] Add protection against $CC=*mingw32*.exe on cygwin

*mingw32*.exe will not build the orca TUI correctly, though it may build
the CLI. If the compiler name isn't specified, like with `-c gcc`, then
it may default to the CC environment variable, which may be set to mingw
gcc instead of 'regular' cygwin gcc. This patch to `tool` fixes this
issue by guarding against the two known names of the mingw compiler .exe
when the detected OS is cygwin, and ignoring them, and instead
specifying `gcc` directly (unless overridden by the user with the `-c`
option.)
---
 tool | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/tool b/tool
index 9920d08..1551cea 100755
--- a/tool
+++ b/tool
@@ -60,6 +60,26 @@ esac
 
 cc_exe="${CC:-cc}"
 
+if [[ $os = cygwin ]]; then
+  # Under cygwin, specifically ignore the mingw compilers if they're set as the
+  # CC environment variable. This may be the default from the cygwin installer.
+  # But we want to use 'gcc' from the cygwin gcc-core package (probably aliased
+  # to cc), *not* the mingw compiler, because otherwise lots of POSIX stuff
+  # will break. (Note that the 'cli' target might be fine, because it doesn't
+  # uses curses or networking, but the 'orca' target almost certainly won't
+  # be.)
+  #
+  # I'm worried about ambiguity with 'cc' being still aliased to mingw if the
+  # user doesn't have gcc-core installed. I have no idea if that actually
+  # happens. So we'll just explicitly set it to gcc. This might mess up people
+  # who have clang installed but not gcc, I guess? Is that even possible?
+  case $CC in
+  i686-w64-mingw32-gcc.exe|\
+  x86_64-w64-mingw32-gcc.exe)
+    cc_exe=gcc;;
+  esac
+fi
+
 verbose=0
 protections_enabled=0
 stats_enabled=0