Windows (namely, Windows XP Home Edition and Windows Vista) is not necessarily the development platform we dreamt of, but as the majority of the user base, notably the video game players, only uses this operating system, we have to make some efforts to support it.
In this document almost only the topic of creating Windows applications from Windows is discussed: for example, no cross-compilation approach is detailed here.
A clear distinction must be made between environments (IDE, shells, command line tools, etc.) and runtimes (libraries mainly). The difference is that environments are used to generate the user applications, whereas runtimes are directly used by the user applications.
It implies that environments are not provided with the user applications, whereas runtimes are. Therefore the licenses that apply depend on the actual context of use [more infos on licenses].
Generally, using environments does not lead to release restrictions (ex: one can use most GNU GPL shells even when creating commercial applications), whereas using runtimes do (ex: using a GPL library hinders from releasing closed-source software).
For instance, products from Cygwin are both an environment (UNIX command line and tools for Windows) and a runtime (dynamic libraries offering POSIX/UNIX primitives for Windows). For our developments, which are mostly LGPL, using the Cygwin environment (shell, tools) should be allowed, whereas they cannot be linked to the Cygwin runtime (cygwin.dll), which would require their being GPL or to purchase specific licenses.
As said before, Cygwin provides a fairly useful environment. The only drawbacks are that the shell is a bit slow, notably for file accesses, that the often subtles differences between Windows and UNIX are often difficult to hide (ex: symbolic links, file permissions, etc.), and that one must be careful with the build settings, since ending with an unappropriate dependency onto Cygwin libraries is quite easy.
Just go to the Cygwin website and download the installer. After having double-clicked on it, one can select always the default settings (ex: install under the root of drive C:). If having enough disk space, at the screen for package selecting, in the root of the tree-like structure, one may click on the right so that the Default label changes to All. This way a great deal of tools will be readily available with no effort on the future.
Providing a minimal shell system able to run configure and make is the goal of the MSYS project. Still more tools are provided with the DTK version (Developer Toolkit). However, the lightweight approach leads to a smaller tool coverage than the one of Cygwin.
These tools are available for download in the MSYS website. Default settings fit perfectly to our needs.
Probably the best solution in this section focusing on UNIX-like behaviour is to use both environments, Cygwin and MSYS, simultaneously. Thanks to the appropriate choice for the PATH environment variable, MSYS tools can be preferably chosen, but, when they are not available, their Cygwin counterparts are then automatically selected.
To do so, first install Cygwin as explained, and then install MSYS and MSYS-DTK.
Another way of dealing with environments is to customize the build system on a per-platform basis: recreating, under Windows, a UNIX-like environment able to execute transparently the original GNU/Linux build system is quite a dull task. One could use an IDE instead, such as Code::Blocks, and only create the appropriate project file, to handle the build from the IDE. It is often much simpler, and the only supplementary task to perform is to release with the application sources a corresponding project file, with all options set accordingly to the needs of your project.
Among the several available IDE on Windows, we favoured initially Code::Blocks since it is free, it has many useful features, it supports multiple compilers and is itself cross-platform: the same project XML file can be used on multiple systems.
We finally used Visual C++ Express 2005, but now the 2008 version is available. We distribute the corresponding project files for OSDL and its prerequesites (from Ceylan to all SDL helper libraries), to be used preferably with LOANI.
As our build system has been made to be developer-friendly under UNIX, it uses multiple UNIX tools, that do not ease the adaptation to the Windows platform. Instead of which, if the goal is just to be able to create the already-developed application onto another target platform, this task is just a matter of setting the correct platform flags, selecting the relevant options and files, and driving the compiler. Surely such IDE are quite enough for this task !
With a given build environment, usually multiple compilers can be used. It is good practice to catch some errors. We used to test the build of OSDL with Intel C++ compiler.
If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!