As I recently faced an issue when trying to build a “portable” library which is using QT and also supports Windows platform. Finally I was
able to run it on Windows (partially).
There are several most commonly used tools:
cmake: “build system” – attempt to have cross platform “make” functionality.
Theoretically all IDEs in the future should support loading, saving
projects in cmake format.
This will allow to build for example Visual Studio project on Linux or
vice versa.
cmake “transparently” generates makefiles/projects (“workspaces”) for
the platform which you are actually using.
nmake: (most commonly mentioned as) implementation of “make”
functionality by Microsoft for Microsoft platforms. Contains a subset
of features of UNIX “make”. Also takes as input a regular UNIX
makefile.
qmake: “build system” by Trolltech which is distributed with QT libraries.
This utility also generates makefiles (and Trolltech projects) but as
input it takes its own “pro” format. qmake is intended to be
proprietary.
mingw: a port of some frequently used GNU projects for Windows. This
package includes GCC for use on Windows platforms. The main purpose of
this is to provide “GCC way” to create Windows based applications. In
other words, mingw is useful if you want to develop a Windows
application but you want to use UNIX makefiles and building tools. In
such a way, an application built with mingw needs only Microsoft
libraries for execution.
cygwin: originally developed to allow building POSIX-compliant
applications on Windows platforms. Currently allows to build and run
many UNIX applications on Windows. Works like emulation layer for
POSIX calls on Windows. In other words, cygwin allows to run all these
UNIX (make, automake, configure, gcc, etc) tools to build software
which is POSIX compliant. After building, such application can be
executed on the same platform using cygwin libraries as emulation
layer for POSIX calls.
Small, but important thing to remember.
Even if some portable library or application is successfully compiled,
this does not always mean it will run “successfully” on the “supported”
platform. Currently there are too many problems which are simply hard to predict so don’t expect a lot of reliability. Still, the best way to run the code is to use the platform on which it was developed.