[CMake] Has anybody tried to use CMake to build software on the MinGW/MSYS/Wine platform?

[Alan W. Irwin]

On 2010-03-29 12:43-0600 Clinton Stimpson wrote:

> On Monday 29 March 2010 12:27:17 pm Alan W. Irwin wrote:
>> Wine (winehq.com) is free (in both senses) software that provides a Windows
>> work-alike that appears (from news stories, I have no personal experience
>> yet) to be fairly mature.
>>
>> Thus, I was wondering whether anybody here had tried MinGW/MSYS/Wine as a
>> platform for building software with CMake?  Note, I am not discussing a
>> MinGW cross-compile possibility.  Instead, I am discussing running
>> MinGW/MSYS and CMake directly under Wine.
>>
>> Currently my only platform is Linux, and I have no practical experience
>>  with the Windows platform (either Wine or proprietary versions) at this
>>  stage. Nevertheless, if the MinGW/MSYS/Wine platform choice is known to
>>  work with CMake, that would motivate me to learn enough about using
>>  Windows so that I could use MinGW/MSYS/Wine on CMake myself.
>
>
> I just tried an experiment and it worked.
>
> === cmakelists.txt ===
> project(hello)
> add_executable(hello hello.c)
> target_link_libraries(hello gdi32)
> ===
>
> Where hello.c was a Win32 "hello world" example grabbed off the internet.
> Then use winegcc and wineg++ as your compiler (that is: no cross-compiling
> setup in CMake).

I have been consulting extensively with Clint off-list since he posted that.
It turns out winegcc is a wrapper for (Linux) gcc which allows you to use
your application on Linux but linked to winelib.  That is useful, but not
what I wanted.  Once that miscommunication was cleared up, Clint went ahead
and used downloaded Windows versions of MinGW and CMake under Wine on Linux
(which when combined with MSYS is what I wanted) and that proof of concept
worked! I have since (slowly) followed what he did, and finally had complete
success as far as I have tested it.  I finally managed to build a simple
test project about an hour ago under wine using downloaded windows versions
of MinGW/MSYS/CMake.  After that breakthrough, I went ahead and built and
tested a minimal PLplot (nothing by C core libraries and C examples) on this
platform, and all was well; the test built and ran our 31 standard C
examples both for our colour and monochrome Postscript devices, and the
results looked good under Linux using gv!

I feel this platform has revolutionary potential.  All components are
written with open-source software freedom and all that implies. MinGW/MSYS
is popular software that averages something like 1500 downloads per hour (!)
at SF (see
http://sourceforge.net/project/stats/detail.php?group_id=2435&ugn=mingw&mode=week&type=prdownload).
Even if you account for the fact that there are something like 20 components
you have to download (if you want all MinGW/MSYS components), those download
numbers obviously represent a lot of developer interest in MinGW/MSYS. I
presume most of that popularity is for developers who are building their
apps on proprietary Windows, but now with Wine and CMake there is potential
for their apps to be built and run by their Mac OS X (at least on x86) and
Linux development buddies with no necessity for paying out Windows licenses,
multi-booting, or running a memory-hog virtual box. Furthermore, with
MinGW/MSYS/CMake/Wine Mac OS X and Linux developers have a simple means of
porting to MinGW/MSYS in general and thus share their apps with their
Windows buddies who have MinGW/MSYS/CMake expertise on proprietary Windows.
Of course, for software projects like PLplot which are
already cross-platform, Wine also has the potential to allow the Unix
developers for the project to help out with build system issues being worked
on by the Windows developers for the project. Finally, the MSYS version of
bash gives a comfortable environment to work in for Unix developers (like
me) who are not familiar with Windows.

I emphasize there is still a lot more testing of this platform for me to do
but the PLplot build I have already done is already quite sophisticated.
So this platform looks quite promising, and I think it should be
straightforward to add many additional components of PLplot such as our C++,
etc., language bindings and additional device drivers that depend on the
GTK+ stack of libraries and Qt stack of libraries (both of which have
downloadable binary versions suitable for MinGW).

Also, I want to thank Clint for being so helpful with my dream; I really
am completely inexperienced with Wine and Windows so I could not have
gotten nearly as far as I did without a lot of help from him.

In sum, I am very happy how the Windows version of CMake plus Wine-1.1.41
(Clint tells me Wine-1.0.1 doesn't cut it) has opened up the very
interesting MinGW/MSYS/CMake platform on Wine.

Here are further details of what I did (a mini-HowTo). This is for those
interested in this platform but who have little Wine or Windows experience
(like me last week).

I used the latest development release of wine (version 1.1.41~winehq1-1
available from the non-official Debian Lenny repository at
http://www.winehq.org/download/deblenny), and downloaded Windows versions of
the following list of MinGW components:

binutils-2.20.1-2-mingw32-bin.tar.gz
gcc-4.5.0_20100311-2-mingw32-doc.tar.lzma
gcc-core-4.5.0_20100311-2-mingw32-bin.tar.lzma
libgcc-4.5.0_20100311-2-mingw32-dll-1.tar.lzma
libgmp-5.0.1-1-mingw32-dll-10.tar.lzma
libiconv-1.13.1-1-mingw32-dll-2.tar.lzma
libmpc-0.8.1-1-mingw32-dll-2.tar.lzma
libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma
libpthread-2.8.0-3-mingw32-dll-2.tar.lzma
mingwrt-3.18-mingw32-dev.tar.gz
mingwrt-3.18-mingw32-dll.tar.gz
w32api-3.14-mingw32-dev.tar.gz

MSYS components:

bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
coreutils-5.97-2-msys-1.0.11-bin.tar.lzma
make-3.81-2-msys-1.0.11-bin.tar.lzma
msysCORE-1.0.14-1-msys-1.0.14-bin.tar.lzma
msysCORE-1.0.14-1-msys-1.0.14-dev.tar.lzma
termcap-0.20050421_1-1-msys-1.0.11-bin.tar.lzma
grep-2.5.4-1-msys-1.0.11-bin.tar.lzma

and cmake (cmake-2.8.1-win32-x86.zip).

I unpacked all this stuff with Linux tar and unzip.  Note these cutting-edge
MinGW/MSYS components are not accessible with the MinGW and MSYS installers
according to the documentation because those installers have not yet been
updated to handle more than older versions of MinGW/MSYS.  However, modern
MinGW/MSYS installers are apparently in the works, and when they become
available, you should be able to just download the installers, and they
would download and unpack every other component that you felt was needed
or which was a dependency of one of your needed components.

After the unpacking I ran winecfg (picked everything as default), and I used
Linux wine regedit (initially)

to edit the PATH variable in

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Session Manager/Environment

to point to the various paths for the MinGW, MSYS, and cmake components.
However, the list of paths got too long for regedit so I ended up
editing this line

"PATH"=str(2):"C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;Z:\\home\\wine\\mingw\\MSYS\\bin;Z:\\home\\wine\\mingw\\MinGW\\bin;Z:\\home\\wine\\cmake\\cmake-2.8.1-win32-x86\\bin"

directly in /home/wine/.wine/system.reg.  (One of the nice things about Wine
is its registry files can be edited by any editor.) I have done all this wine
platform work under the "wine" user account to keep it separate from
everything else on my development machine.

After that, I had access to a good bash environment on Windows using

wineconsole /home/wine/mingw/MSYS/bin/bash.exe

from which I coud build my simple project using the commands

cmake -G "MSYS Makefiles" \
/z/home/software/plplot_svn/HEAD/test_cmake/test_c_library_build > cmake.out
make > make.out

Note both commands were quite noisy with _many_ repeated warnings output
into stderr by Wine concerning some Alsa troubles for a sound-capable TV
card I happen to have installed on my system (of all things).  Once I obtain
more than a few hours of Wine experience I hope to be able to get rid of
that warning message noise, but for now I ignore those warnings by capturing
useful stdout output to cmake.out and make.out as above.

Once I copied the built shared library (which performs the onerous task
of outputting "hello, world") to the directory where the app
was located that linked to that library, then success!

wine at raven> wine Demo/helloDemo.exe 
hello, world

The build of PLplot was similar.  For Windows there is no equivalent of
rpath so our Windows developers have done something to our build system
to put all the dll files in the dll subdirectory of our top-level
build directory.  Once
I augmented the PATH under bash.exe using

PATH=$PATH:`pwd`/dll

then "make -j4 test_noninteractive" worked fine (and saturated the two
processors on my box).  (That test target has good
dependencies so it builds everything required to run our examples, and then
generates file results for all our 31 standard examples using all available
bindings and all available file-oriented devices.)

So far so good with this platform, and I look forward to adding additional
components of the build and test of PLplot on this platform.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________