I spent some time today trying to get a clean build of mingw and nanomsg.
I failed, utterly.
After struggling to get AppVeyor to be able to build cmake + mingw, I then
started tackling the problems. gmtime_r isn’t exposed properly, neither is
_sprintf_s. Those were relatively easy to address, if annoying by
requiring extra #ifdef spaghetti.
But, then I ran into a bajillion problems in Winsock. It seems that mingw
doesn’t expose the same definitions we need in Winsock. Perhaps it is only
exposing the legacy Winsock API from Windows XP and earlier. I don’t know.
And I don’t care.
I’m hereby formally stating, nanomsg does not support mingw / gcc on
Windows. Visual Studio is a free download. You can use a CLI with cmake
to build even.
I cannot and will not invest my time and energy to support a compilation
environment solely for its own sake. There is no justification for doing
so, when Visual Studio can be used for the same uses that mingw can; trying
to support a mutant platform / environment is simply NOT worth the added
complexity.
*THAT* said, if someone can show me some simple compilation flags that turn
mingw into a sane environment, which properly exposes the full Win32 API.
I’m happy to support that. But from what I can tell, the environment that
mingw exposes is *different* than the one Studio exposes. (Even if its a
compile time difference only.)
I’m hereby closing all “Fix MinGW … blah blah blah” bugs as WILL NOT FIX.
If someone else has the energy and wants to add that complexity, and
sustain it, please feel free to fork it on github. :-)
- Garrett
