Automate builds for Windows and Mac and utilize github release system about flips

[DarkSamus669]

Why not linux?

[Miepee]

@Alcaro Heya, i'd be interested in submitting a PR for this.
I have started toying a little bit around, and currently thought of the following:

• PRs: build unoptimized GUI for win/lin/mac to ensure PR doesn't break
• master: build optimized GUI and upload them as artifacts. (Could also create releases, if that's wished for)

Current issues I encountered, that I would appreciate help with:

• Macos straight up fails compiling on its default compiler because Apple's LLVM doesn't support -fopenmp. I can work around this by using llvm from homebrew, but it'd be nice if the shipped compliler would just work ootb.
• flips-gtk.cpp and flips-win32.cpp seems to be always included. For me this caused windows to always need gtk3 libs to compile.
• Using Msys2+mingw to compile on windows I have been getting C:\Users\RUNNER~1\AppData\Local\Temp\cc5QXajF.o:libbps-suf.cpp:(*ABS*+0x0): multiple definition of '.weak.__cxa_pure_virtual._ZN4fileD2Ev'; C:\Users\RUNNER~1\AppData\Local\Temp\ccePAcuC.o:D:\a\Flips\Flips/flips.cpp:14: first defined here
• If finding GTK libs fails when targeting GTK, it will just switch over to building CLI, instead of failing. (Isnt difficult to fix, i can do a seperate PR for this)
• Optimized builds only seem to exist for linux? Or is "just append -O3" the optimization flag for the other OS'es?

[Alcaro]

Sure, sounds good to me.

• There is no mac GUI (unless the GTK one works? I didn't try), but feel free to build CLI for mac. Personally I don't care about mac, but if you want to add build scripts and/or a GUI, I'll merge it.
• I have a Travis-CI already, but I don't know how comprehensive it is. Feel free to replace it, I'm not particularly attached to any specific CI backend.
• Releases should be either every commit, or never. Regular releases work fine for anything with regular development, but Flips development is too sporadic to have any kind of schedule.

Issues:

• I don't like openmp either; I'd prefer if someone could rewrite libdivsufsort to use std::thread or something so we can delete that dependency, but until and unless someone does, using it gives a nice performance boost. But yes, do turn it off on unsupported platforms; tying it to the GTK UI makes no sense, but it works for me and I never bothered thinking of a better Linux detector. If you can think of one, go ahead.
• Did you try running make.sh on Windows? It's designed for Linux only, it probably does something weird (like compiling the GTK UI) on windows. I use https://winlibs.com/ in Wine for my Windows compilation needs, so I can't test make.sh in msys; if you can fix it, that would be welcome.
• That's ... weird, yes. It works for me with CFLAGS=-O2, but not in debug builds. Wonder how that ever worked... probably a leftover from an older mingw version. Fixed.
• I felt that a CLI-only binary is better than a compile error, but yes, switching such big things isn't the ideal approach either. Feel free to change that, as long as the resulting error is clear on how to ask for a CLI build.
• Fully optimized builds use LTO and PGO and pretty much every compiler flag I could find. Optimized Windows builds are created by make-maintainer.sh, which is a huge mess, I won't bother defending myself. Feel free to clean it up.

[Miepee]

issue 2: nope, I just ran the makefile directly via TARGET=windows make.

[Miepee]

RE GTK GUI: that one actually works on all OS; Linux, Macos and Windows since it's a cross platform GUI toolkit.
But I also don't feel like changing windows to use the GTK UI, because that one probably looks worse on windows than the native controls. Haven't actually tested this though.

[Alcaro]

Then the build should use the Windows GUI, and flips-gtk.cpp should compile to an empty object file that doesn't depend on anything. If you figure out what it's doing, do tell, it sounds like a quite nasty bug.

Compiling the GTK GUI on Windows may work, but I don't recommend it. I haven't tried it either, but I'm quite sure it will screw up around icons, file associations, and filenames unrepresentable in the current codepage. You're welcome to try if you're bored, but we're not deploying that to production.