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

[Even Rouault]

Le mardi 31 mai 2016 17:31:06, Rashad Kanavath a écrit :
> 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 ?

I mean having a choice per-driver, especially for those that depend on 
external libs., to decide if they are included in libgdal.so or if they must 
be standalone plugin (or potentially not compiled at all). 


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