[gdal-dev] Building GDAL on Windows 32 and 64 bit
damian.dixon at gmail.com
Tue May 31 05:24:15 PDT 2016
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
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
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
On 31 May 2016 at 13:00, Jeff McKenna <jmckenna at gatewaygeomatics.com> wrote:
> On 2016-05-31 8:46 AM, alex wrote:
>> Hi Dmitry and others,
>> I can see that you are making a great effort, and as far as I can tell
>> with great progress too.
>> Do you know why the rest of the list is silent on this? Are the GDAL
>> developers not interested in cmakeification or are they in silent agreement
>> with your approach?
> I for one am not interested in 'cmakeification' of GDAL. For the
> MS4W community, I build 32 and 64 bit versions, for the full stack of
> Apache, PHP, MapServer, GDAL (I counted recently and it is now over 200
> libraries) - and the few projects that use cmake are the troublesome ones.
> (for example, MapServer switched to cmake but no one is maintaining the
> mapscript parts of cmake, which means I have kept my own makefiles alive,
> in order to build all of MapServer).
> I am very against cmake, I have had terrible experiences. I am all for
> sharing our makefiles and making life easier, than using a fancy cmake
> system that is not maintained.
> Jeff McKenna
> MapServer Consulting and Training Services
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev