[CMake] MinGW Compilers on Windows

[Alan W. Irwin]

On 2017-12-10 09:18-0500 Kevan Hashemi wrote:

> Dear Alan,
>
>> If you need/prefer Unix tools provided by MSYS to build your software,
>> another possible generator you should look at is "MSYS Makefiles".
>
> Thank you for this suggestion.
>
> The CMake configuration and generation of OpenCV completes without errors 
> using "MinGW Makefiles". I get one warning:
>
> CMake Warning at cmake/OpenCVPackaging.cmake:23 (message):
> CPACK_PACKAGE_VERSION does not match version provided by version.hpp header!
>
> I assume that's a minor OpenCV-related error. When I "make", however, I enter 
> some alternate shell program with a Microsoft copyright at the top. I suspect 
> this is because I have sh.exe in my MSYS path, having seen this mentioned 
> along the way, but if I remove sh.exe from the MSYS path, MSYS won't even 
> execute "ls", so I'm not sure how to fix that problem, nor do I understand 
> why it is a problem.
>
> When I use "MSYS Makile", on the other hand, the OpenCV configuration and 
> generation completes without warnings. When I "make", off it goes, compiling. 
> After editing MinGW's commctrl.h file to solve an error related to OpenCV, 
> the make completes and I have OpenCV built completely, which is really cool. 
> I looked through the Makefile and it is awesome.
>
> I'm curious as to why the "make" for the MinGW generator does not work. But I 
> have a working build procedure, so I'm all set.

Hi Kevan:

Glad everything is working for you with "MSYS Makefiles".

Just to follow up on the "MinGW Makefiles" issue you ran into, it has
a test for sh.exe in the PATH, and if it finds it, it (rightly)
refuses to configure.  As far as I can tell using the "strings"
executable, mingw32-make.exe (the MinGW version of make you should use
with this generator) depends on sh.exe so I presume that means it has
different behaviour if sh.exe is in the PATH and the generator test
for "MinGW Makefiles" is designed to avoid that alternate behaviour.

So if you are further interested in the "MinGW Makefiles" generator,
you should remove all sh.exe versions from your PATH (including sh.exe
provided by raw Windows), get into a CMD environment, execute cmake
with the "MinGW Makefiles", and then build your software with

mingw32-make.exe

which internally uses CMD commands rather than Unix shell commands
to build software.  Note you should keep sh.exe out of your PATH not
only for the configuration stage, but also the build stage (to
avoid that presumed alternate behaviour of mingw32-make.exe in that
case).

For the Wine version of Windows I found this method of building
software was quicker than building using the "MSYS Makefiles"
generator.  I assume that is because the CMD environment is faster
than bash.exe. One complication for us is our PLplot test system
depends on bash scripts so requires bash.exe and other Unix tools to
be available.  So I tricked "MinGW Makefiles" into working fine with
our test system by putting a copy of MSYS in my path *but with sh.exe
removed*.  Thus, the build and test fundamentally depends on a CMD
environment, but most of the test commands executed in that
environment for us correspond to CMD executing bash.exe to run the
test scripts.

The above is from my own extensive but likely now dated experience
with MinGW/MSYS/Wine. My understanding from other's experience is the
MinGW-w64/MSYS2 platform has a similar "split personality" where you
have to very carefully distinguish between make versions from the
"mingw" versus "msys" repositories (with the former using CMD commands
to build and the latter using Unix shell commands to build) when using
the "MinGW Makefiles" generator versus the "MSYS Makefiles" generator.

I hope the above discussion allows you to have success with "MinGW
Makefiles" so you can compare its results with the corresponding "MSYS
Makefiles" results.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________