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). -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
