[gdal-dev] Building GDAL on Windows 32 and 64 bit

Jeff McKenna jmckenna at gatewaygeomatics.com
Tue May 31 05:42:50 PDT 2016

On 2016-05-31 9:24 AM, Damian Dixon wrote:
> I'm going to take the slightly opposing view...
> I would prefer CMake to be supported particularly for generating WIndows
> builds as the nmake build is painful to configure and maintain. I spent
> ages getting our original build working with the configurations I
> needed, way more time than I expected.
> For general Linux/Solaris I don't particularly care if 3rd party
> libraries such as GDAL are CMake or make/autoconf as these tend to just
> work as long as they have been crafted correctly for cross compilation.
> Our internal build system on non-Windows is built around CMake and we
> have CMake functions to build 3rd party libraries using many different
> build approaches.
> I've found that there are some very bad configurations for autoconf and
> for CMake out there. Some so bad that I've had to craft my own CMake or
> makefile.
> In general I prefer CMake as it allows me to build a library on Windows
> or Linux without worrying about nmake, visual studio version or makefile
> platform/configuration.

Yes you touched on why cmake is popular - with non-Windows environments 
and supporting many platforms. However if the question is for building 
GDAL on Windows (and this is what we are talking about), then there is 
no question that makefiles are the easiest.  To please code maintainers 
cmake is used because it is easier to maintain for so many platforms; 
I've seen several projects make this switch, and not a single person is 
maintaining the Windows part of cmake in their code.  It's like the 
cmake switch means to many that "oh ok Windows is supported by cmake I 
assume", which is not the case.

Again, I can only speak from experience.  I wish that magically I am 
wrong for GDAL, and cmake on Windows is maintained for each and every 
GDAL driver :)  (whoa that is a big wish)


Jeff McKenna
MapServer Consulting and Training Services

More information about the gdal-dev mailing list