On November 18, 2015 3:53:29 PM EST, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
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
