search

nanomsg / nng

nanomsg-next-generation -- light-weight brokerless messaging
https://nng.nanomsg.org
MIT License
3.63k stars 472 forks source link

Fixes #1825 Compiler warnings / errors from new logging feature on Window #1826

Closed shikokuchuo closed 1 month ago

shikokuchuo commented 2 months ago

fixes #1825 <Compiler warnings / errors from new logging feature on Windows>

The first commit should be uncontroversial.

The second is good enough for me as I don't make use of logging. But a cleaner solution would be to have an alternative that works, or a CMake option that disables logging entirely.

Note that the above format should be used in your git commit comments. You agree that by submitting a PR, you have read and agreed to our contributing guidelines.

gdamore commented 2 months ago

I need to think about this. I don't like that we continue to carry diffs for MinGW compilers specifically because they cannot be bothered to expose standard APIs. Supporting Windows alone is hard enough, but dealing with their down-rev compilers with a bunch of compiler workaround is obnoxious.

My preference is that for folks who need to build for Windows, they use a proper compiler supported for the operating system. MinGW fails in that regard, since it misses standard documented Win32 APIs. (This is just one case.)

(Notably also they have a pthreads implementation of clock_gettime(), but that requires linking against pthreads, which is bonkers on a Windows platform.)

If we do this, I'm of a mind to emit a large warning during CMake that you are using a non-standard configuration and will miss functionality, and that I don't want to hear complaints about it.

If I seem bitter about this, it's because it's not the first time I've been burned by MinGW deficiencies. People building for Windows should either use one of the commercial options (and notably VS is free for individual use via the community edition), or perhaps clang.

Of course, if the MinGW folks would be more willing to update their tools to not suck (so that access to all Windows standard APIs were available), I would probably feel a lot less hostile towards them.

I have almost zero sympathy for the "but Visual Studio is not open source!" argument, since the underlying platform is completely proprietary as well. If you want to develop exclusively using open source tools, you have no business working on Windows at all.

gdamore commented 2 months ago

(Notably I also have approximately zero sympathy for commercial developers who won't spring for a compiler license and instead demand that I support their use of deficient free tools. As doing this comes at a cost to me, and to the project, such an attitude by commercial developers is simply selfish IMO. Perhaps they should instead demand that the producers of those other free tools fix them to not need workarounds, or maybe contribute back to those tools either code or money to fix them.)

gdamore commented 1 month ago

Closing in favor of #1834

Upshot is that Windows MinGW users need to use MinGW-w64 with the UCRT. I have no interest in supporting other cases of MinGW -- Visual Studio remains the "officially supported" compiler for this project on Windows.