Build setup for MinGW compiler

[ghost]

I have created a makefile, bat script a new folder (mingw) and appropriate defines so that the console version can be built using MinGW on Windows. I did it in such a way that it is not interfering with the current setup and architecture of the code.

I have personally tested it (GCC 7 x64) and am using the binary daily (I still use elvis as my vi-compatible editor of choice).

I also attempted to do the same for the gui version but the WINAPI it is using is extremely outdated (Windows 95/98 era) and while I got it to compile, it does not start on modern Windows systems, so I did not include it in the pull request.

[mbert]

Thank you for this. Could you squash the separate commits to one? We don't use sepearate commits one per file.

Also, extending the installation guide in INSTALL would be great. There's a section on Windows, you might just add a subsection there.

[ghost]

No problem, I'll squash them tonight and make the changes you suggested for the INSTALL documentation. The PR should update as soon as that happens since it's not dependent on any branch merging, just on master changes.

[ghost]

So I added the Windows information in the INSTALL file, pushed and then squashed all previous commits (except the first PR I sent for wait()). Ideally I should have made a branch and merged as I had to squash HEAD~5 which isn't ideal..

[mbert]

OK, so I guess you will open a new pull request for the commit containing your above changes?

[ib]

Shouldn't a (one) config.h file be generated?

[mbert]

Looks like for mingw32 there is no configure script used; hence the file config.h is static and not generated.

[ib]

Well, it should follow at least the method of makwin32.bat then and not fiddle around with elvis.h and oswin32/*.c files.

[ghost]

@ib I would hardly call adding appropriate macros for defining systems 'fiddling'. It is a standard practice that has been used for decades in C programs. Of course, I would do it a cleaner way. For one, not expecting that oswin32 will be compiled with Visual Studio which imports elvis.h in a non-standard way.

If you are compiling code in a UNIX-like fashion, why on earth would a required header file be declared in the same location when in-fact, it isn't? Hence the 'fiddling' (improving) of the imports. It is fundamentally flawed. Unless you would be kind enough to provide a better solution for MinGW with a working PR?

And yes, MinGW doesn't use ./configure and never has. That would be msys2 and cygwin.

@mbert yes I will be cleaning my fork and will open a nice clean PR for you to merge.

[ib]

@atsb: So you can't copy MinGW's osdef.h over oswin32/osdef.h and its config.h into the top srcdir and include it from there?

[ghost]

I can, but it wouldn't solve anything and it is messy.

[ib]

It would leave seven unnecessarily changed files untouched and add only four necessary new files which sounds anything but messy to me.

[ghost]

Except elvis.h is still required for the .c files under oswin32/ which is not in oswin32/ but in the top src dir.