Deprecate mingw; support clang on windows instead

[mlabbe]

Mingw via msys2 is in disrepair. A fresh install of their latest (as of 3/6/2019) provides a gcc that fails with nonzero errorlevel and no error messages compiling the source. Numerous unjustifiable issues were encountered building a toolchain that gets to this point including dead wiki links, a totally janky package manager experience and a bunch of other bugs. I didn't have a great time back in 2015 when I set this up, either.

Mingw via msys2 can still work via makefile, but it would be unsupported (no test builds by the developer, no support in the documentation). I do not want to encourage people to use buggy toolchains. If mingw via msys2 ever gets its act together, it can compile, but I don't want to spend any more time on something that is clearly under maintained, as it creates a hard road for developers to even begin working with NFD.

Supporting a non-msvc compiler on Windows has value. clang's toolchain on Windows has matured greatly since NFD was first announced. Supporting warnings-free compilation using llvm using the gmake_windows build dir and gnu make is a feasible feature to support, as is using clang inside of msvc via project files.

The time I spent wrangling msys2 can be used on hooking up asan for the tests.

If there is a valid reason to continue supporting mingw in addition to llvm, please use this issue to explain the reasons. I will start in on the deprecation path in a few months.

[DanielGibson]

(I'm not using this lib currently, but I would if I needed a file picker in an application that doesn't use a UI toolkit that brings its own like Dear ImGui)
One thing MinGW might be attractive for is crosscompiling for Windows (when you're on e.g. Linux).
AFAIK doing that with clang is somehow possible, but needs manual setting up (and probably still uses MinGW's headers then).

OTOH, you could just stop actively maintaining it while trying not to break it and let people who actually use it send patches if it does break after all..

[dleslie]

https://visualstudio.microsoft.com/visual-cpp-build-tools/

[ToriningenGames]

I agree that MSYS2 is a mess. I don't like it either.
But, Mingw is still fine to use on Windows, and, if you don't like VS, is basically your only option.
Most free IDEs that aren't VS use Mingw's GCC and Make, as far as I can tell. Clang is not a drop-in replacement for these.
I find it much easier to use Mingw without MSYS. Mingw has all the pieces needed to build on Windows, allowing for MS's different "shell". A little bit of twiddling (Defining CC on command line, removing a erroneous redundant mkdir, moving one initialization so a goto doesn't cross it) and it builds with only a warning about redefining _WIN32_WINNT. Works fine too.

tl;dr: Go ahead and drop MSYS support, but retain Mingw support, please.

[fedor4ever]

Up for winxp and mingw(with -w64 too) support.

[syskrank]

Nothing is wrong with using MinGW, imho.
Standalone archives are working pretty well apart from the MSYS. The latter is garbage, indeed.

There are a lot of cases for utilizing MinGW in such IDEs as CLion and QtCreator.
Also, MinGW is a powerful option for cross-compiling for Windows on a Linux host.
BTW, is there any clean way to "just cross-compile" NFD? :)

What exactly do you mean by "deprecating mingw" ? Dropping premake/make targets for Windows environment?
If it's only a build system-wise decision, it is acceptable.

[mlabbe]

Thanks for everyone's feedback. I have decided to keep mingw.

The code in devel branch as of change 081cce2 works for Mingw compilation.

Please give it a test and report back with new issues if they come up.

Note that the change contains specific instructions on how to get and configure Mingw to build Native File Dialog in build.md.