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

[Rashad Kanavath]

On Tue, May 31, 2016 at 4:06 PM, Even Rouault <even.rouault at spatialys.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?
>
> 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)
>

Hello Even,

You mean libgdal.so or whatever contains only gdal core libraries and all
others are plugins ?

Or you mean to go one more level and split gdal-core.so, gdal-port.so... +
the above plugins.


>
> > 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160531/8fdcfbad/attachment-0001.html>