add mingw compatibility

[kanonet]

msys+mingw use unix-like file system not windows
fix +1406

[wojdyr]

@kanonet I haven't tried it yet, because I don't have Windows at hand. But I see that it changes the same line as the patch from MSYS2 distro.

Could you write what configurations have you tried? I see that you have OR in NOT (MSYS OR MINGW). I'm asking because various configurations are possible: MSYS or MSYS2 or MinGW without MSYS; Python from MSYS2 package or normal Windows Python, etc.

[kanonet]

@wojdyr The Idea for this PR was taken from MSYS2 patch of cause.
I think the solution from original patch could break other compilers that expect a windows file system and not an unix like. So I decided to just check against MSYS or MinGW.
I use MSYS2+MinGW+included Python, I did not test with MSYS(1) or pure MinGW, but I dont think my PR will break them.
For documentation: When I use MSYS2+MinGW with '-G "Unix Makefiles"' CMake variable MINGW gets set, but MSYS does not. If I use '-G "MSYS Makefiles"' both variables MSYS and MINGW get set.

I did not succeed in building pybinds tests, but this allows to build pybind when it is shipped with other projects (like dlib), so those can get build. IMHO this is good enough for the moment. :)

[dmikushin]

@kanonet Thank you for your work. Without your patch, Python libraries are not found. The patch unbreaks pybind11 on the latest msys2 (20190524). I've tested the msys64-mingw32 config, where the python executable path has to be given explicitly:

cmake -G "Unix Makefiles" -DPYTHON_EXECUTABLE=/mingw32/bin/python3 ..

Otherwise, it picks up python from mingw64, while the session is mingw32 and complains on compiler-python arch mismatch. This seems to be msys-specific though.

[wjakob]

Ok, I'll go ahead and merge this then.

[Baljak]

This modification somewhat broke compilation with MinGW when using it without MSYS. Because, by default, MinGW does not require libpython3X.a: it works perfectly well with python3X.lib.

Furthermore, Python 3.8 does not provide libpython38.a anymore (and Anaconda did not provide it even before 3.8):

The libpython38.a file to allow MinGW tools to link directly against python38.dll is no longer included in the regular Windows distribution. If you require this file, it may be generated with the gendef and dlltool tools, which are part of the MinGW binutils package:

gendef python38.dll > tmp.def
dlltool --dllname python38.dll --def tmp.def --output-lib libpython38.a

The location of an installed pythonXY.dll will depend on the installation options and the version and language of Windows. See Using Python on Windows for more information. The resulting library should be placed in the same directory as pythonXY.lib, which is generally the libs directory under your Python installation.

(Contributed by Steve Dower in bpo-37351.)

Source: https://docs.python.org/3/whatsnew/3.8.html

[wjakob]

@Baljak , @kanonet , @dmikushin : I have no experience with MinGW/MSYS. Please create a PR if you would like further changes here.