On Tue, May 31, 2016 at 6:23 PM, Even Rouault <even.roua...@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.roua...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev