feat: Restore Windows build

[gombosg]

Closes #4

This is a long project. It already configures, generates UI files and gets to about 30% build. From here on, it's a matter of fixing build errors one by one and re-adding packaging stuff like Windows icons and installers.

It's easy because I can just take a look at antimicro code and copy over whatever's needed, but it's also long and risky (however much I work on this, it may not be successful...).

[gombosg]

I also merged #112 into here, it'll end up on master soon anyway and that library also didn't work on Windows.

[AriaMoradi]

It's better to not touch .gitignore @gombosg

[gombosg]

Could you elaborate? It's there to exclude build-generated stuff from git. I mostly know what I'm doing. :)

[pktiuk]

I am not sure about this way of working with restoring windows support.
I think it would be better to have a single branch with fixes for windows and merge to it via PR to keep history clean (and maybe rebase it from time to time), or maybe we should just merge these changes to master (like this FindSFML2.cmake).

[gombosg]

I don't see where the problem is, this is standard git workflow. These commits will be squashed anyway on merge. Merging master into a feature branch every now and then is standard procedure to keep them updated. (At least we do it a t $DAYJOB 🙂)

(And personally I find it much better than rebasing because rebasing modifies branch history and makes it nearly impossible to collaborate on a branch.)

I'm not sure if merging half/non-working code to master is a good idea. If the project turns out to be not working after all or is abandoned, then we are either left with dead code in master or we have to revert. So we don't win much by that.

[pktiuk]

These commits will be squashed anyway on merge. Merging master into a feature branch every now and then is standard procedure to keep them updated. (At least we do it a t $DAYJOB slightly_smiling_face)

I am not sure whether squashing so many changes into one commit is a good idea, It will make a history of development not very clear.
That's why we are using rebase when possible at my $DAILYJOB 😉

rebasing modifies branch history and makes it nearly impossible to collaborate on a branch

Yes, it makes nearly impossible collaborating when many people are working on a single branch, but currently there are only 3 of us and we could notify each other when we want to rebase to get some needed change from master. (we don't have to do it very often).

[gombosg]

If this ever gets merged, I promise to make an interactive rebase, squashing unnecessary commits. 😄

[Yay-mod]

can you make a version that work on windows subsystem for linux

[pktiuk]

Do you remember why quit shortcut functionality is removed here?

[pktiuk]

You started this restoration well, but it may be difficult to merge it (due to big changes I've made during last year).
I will try to do it in my way.

#220

[pktiuk]

I won't delete this branch yet, because there may be still something useful