<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 6:23 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Le mardi 31 mai 2016 17:31:06, Rashad Kanavath a écrit :<br>
> On Tue, May 31, 2016 at 4:06 PM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > > On 2016-05-31 8:46 AM, alex wrote:<br>
> > > > Hi Dmitry and others,<br>
> > > ><br>
> > > > I can see that you are making a great effort, and as far as I can<br>
> > > > tell with great progress too.<br>
> > > ><br>
> > > > Do you know why the rest of the list is silent on this? Are the GDAL<br>
> > > > developers not interested in cmakeification or are they in silent<br>
> > > > agreement with your approach?<br>
> ><br>
> > As far as I'm concerned, it is more I don't have much experience with<br>
> > setting<br>
> > up cmake build system, so I can't really help.<br>
> > One issue I see with the approach that has been taken is that it mixes<br>
> > both a<br>
> > new build system + a tree re-organization. So it means there cannot be a<br>
> > transitionning phase where cmake would be a in-tree alternative<br>
> > experimental<br>
> > build system that would grow over time until being feature complete<br>
> > (drivers<br>
> > and OS support), with the others one still being the "official" ones. The<br>
> > out-<br>
> > of-tree approach probably makes the potential for external contributions<br>
> > a bit<br>
> > less likely.<br>
> ><br>
> > I haven't looked deeply enough at Dmitry's work but what I'd enjoy to see<br>
> > from<br>
> > a new build system is a more modular way of building drivers. Currently<br>
> > our build scripts do not allow to easily select if a driver must be<br>
> > built in the<br>
> > core lib or as a plugin in a separate shared object, so the former (all<br>
> > built<br>
> > in) is what is done generally. Which can cause packaging headaches since<br>
> > the<br>
> > packager has to make choice of which external library GDAL should depend<br>
> > on,<br>
> > which has consequences on the effective licensing of the lib (for ex,<br>
> > seeing<br>
> > <a href="https://packages.debian.org/sid/libgdal20" rel="noreferrer" target="_blank">https://packages.debian.org/sid/libgdal20</a> linking against poppler make<br>
> > GDAL<br>
> > use effectively bound to GPL)<br>
> > I can in fact imagine 2 uses cases:<br>
> > - you are a packager, download all the dependencies and build GDAL core,<br>
> > built-in drivers and plugin drivers all at once, but generating separated<br>
> > packages gdal-lib, gdal-bin, gdal-pdf, ...<br>
> > - the case of proprietary drivers where some distributions cannot<br>
> > distribute<br>
> > the resulting non-free binary, hence requiring the user to build it from<br>
> > GDAL<br>
> > sources + SDK. So you have those gdal-ecw-build scripts currently that<br>
> > are managed out of tree. Would be cool if the main build system would<br>
> > allow to build those plugins as a separate target from building the core<br>
> > lib (possibly<br>
> > rebuilding only the driver you're interested in, while using the system<br>
> > core<br>
> > lib)<br>
><br>
> Hello Even,<br>
><br>
> You mean libgdal.so or whatever contains only gdal core libraries and all<br>
> others are plugins ?<br>
<br>
</div></div>I mean having a choice per-driver, especially for those that depend on<br>
external libs., to decide if they are included in libgdal.so or if they must<br>
be standalone plugin (or potentially not compiled at all).<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>Yes. cmake can help in that direction. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>