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

[Even Rouault]

> 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?

As far as I'm concerned, it is more I don't have much experience with setting 
up cmake build system, so I can't really help.
One issue I see with the approach that has been taken is that it mixes both a 
new build system + a tree re-organization. So it means there cannot be a 
transitionning phase where cmake would be a in-tree alternative experimental 
build system that would grow over time until being feature complete (drivers 
and OS support), with the others one still being the "official" ones. The out-
of-tree approach probably makes the potential for external contributions a bit 
less likely.

I haven't looked deeply enough at Dmitry's work but what I'd enjoy to see from 
a new build system is a more modular way of building drivers. Currently our 
build scripts do not allow to easily select if a driver must be built in the 
core lib or as a plugin in a separate shared object, so the former (all built 
in) is what is done generally. Which can cause packaging headaches since the 
packager has to make choice of which external library GDAL should depend on, 
which has consequences on the effective licensing of the lib (for ex, seeing 
https://packages.debian.org/sid/libgdal20 linking against poppler make GDAL 
use effectively bound to GPL)
I can in fact imagine 2 uses cases:
- you are a packager, download all the dependencies and build GDAL core, 
built-in drivers and plugin drivers all at once, but generating separated 
packages gdal-lib, gdal-bin, gdal-pdf, ...
- the case of proprietary drivers where some distributions cannot distribute 
the resulting non-free binary, hence requiring the user to build it from GDAL 
sources + SDK. So you have those gdal-ecw-build scripts currently that are 
managed out of tree. Would be cool if the main build system would allow to 
build those plugins as a separate target from building the core lib (possibly 
rebuilding only the driver you're interested in, while using the system core 
lib)

> 
> 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. 

Jeff,
It sounds your issue with cmake is more mapscript not receiving attention, 
rather than a defect from cmake itself, right ? I've used cmake to build QGIS 
on Linux & Windows and can't recall any particular issue I can really 
attribute to cmake (besides Windows being a pain for me in general :-))

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com