Deprecating Windows as development platform
In this entry i will explain how we got ride of Windows as development platform for the CLAM project still providing Windows binaries by using the tandem mingw32 (for Linux) and Wine. We dealt with crosscompilation of most of CLAM dependencies such as Portaudio, Asio, libsndfile, liboggvorbis, pthreads, fftw3, libmad, id3lib, XercesC, libxml++, NSIS and Py2Exe.
After a very dissapointing and fustrating effort from Pau and me of trying to have a reproducible build environment for CLAM based on Visual Express 2005, we decided that the whole thing was foolish and decided give mingw a try.
I am proud of not having a Windows box available at home ;-) but that doesn’t mean i cannot contribute to that part of the development so the last days i did an spike on having mingw crosscompiling CLAM from Linux! We succeeded to compile it all, the dependencies, CLAM and the applications. Because some dll conflicts when installing that could not go into the 1.1.0 version of CLAM. After a gutsy update we could compile it all, so expect rewamped windows binaries for the next release… and maybe development binaries. You can already give a try to the latest svn snapshots.
The key point has been using Wine to install with their own windows installers some libraries and tools such as Qt4, GTK (for pkg-config, libxml++ and dependencies), and NSIS to build windows installers from Linux!
Wine and mingw are a great tandem to compile and test the binaries. Also SConstruct has been a nice tool to hack a quick build environment for third party libraries when the one provided (normally based on autotools) was too messy to get on with.
We kept a reproducible log of the mingw crosscompilation at the clam wiki. This includes how to get all the dependencies working, which may be usefull for you own project. CLAM dependencies we addressed were: Portaudio, Asio, libsndfile, liboggvorbis, pthreads, fftw3, libmad, id3lib, XercesC, libxml++, NSIS and Py2Exe.