Utterly reasonable. Though, it makes sense to extend a warm invitation for
a MinGW contributor/maintainer to step forward before some deadline.
After this point, IFF no takers, it probably makes sense to remove
preprocessor and CMake conditionals for the MinGW platform altogether.
Since, partial support is worst case for all.
Kind regards,
-Jack R. Dunaway
On Wed, Nov 18, 2015 at 2:53 PM, 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
