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

[Rashad Kanavath]

On Tue, May 31, 2016 at 6:23 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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).
>
> Yes. cmake can help in that direction.

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



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