<div dir="ltr">While autoconf isn't pretty, it has done me the least amount of harm of any of the major build systems.  Without patches for the downstream packagers and CI (travis/appveyor), I would be -1.  e.g. debian/ubuntu, redhat/centos, macport/brew/fink, and others<div><br></div><div>With those patches, I'm -0.</div><div><br></div><div>BTW, It's not unreasonable to have separate build systems.  It's work, but very doable.  I maintain a bazel build environment.  I have to notice add or deletes of files in upstream, but it's been working for more than a decade.  <div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 28, 2017 at 11:11 PM, Alexander Bruy <span dir="ltr"><<a href="mailto:alexander.bruy@gmail.com" target="_blank">alexander.bruy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While I'm not GDAL developer or regular contributor (submitted only<br>
few patches),<br>
but still often build GDAL trunk on WIndows and Linux, and less often on Mac.<br>
<br>
Personally I think that solution proposed in<br>
<a href="https://trac.osgeo.org/gdal/ticket/7080" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>ticket/7080</a><br>
is more preferable. It does not require *all* dependencies to be build<br>
with cmake,<br>
it does not require maintaining forks with special directory structure for *all*<br>
dependencies, it plays well with conventions/packages provided on all systems<br>
out of the box. Maybe borsch is good for in-house use when all stack<br>
is build from<br>
scratch but it is not suitable for real-world use cases.<br>
<br>
Of course, #7080 is not ideal, there are some issues, but as I understand the<br>
work is not over and most (if not all) issues can be solved.<br>
<br>
Just my 2c.<br>
<div class="HOEnZb"><div class="h5"><br>
2017-10-28 0:06 GMT+03:00 Dmitry Baryshnikov <<a href="mailto:bishop.dev@gmail.com">bishop.dev@gmail.com</a>>:<br>
> Hi,<br>
><br>
> As Even said it make sense to move discussion from this ticket<br>
> (<a href="https://trac.osgeo.org/gdal/ticket/7080" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>ticket/7080</a>) to the list.<br>
><br>
> First of all I would like to make small introduction to Borsch project. Here<br>
> it is some useful links:<br>
><br>
> * Borsch repository: <a href="https://github.com/nextgis-borsch/borsch" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch/borsch</a><br>
><br>
> * Presentation on FOSS4G 2016:<br>
> <a href="http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf" rel="noreferrer" target="_blank">http://nextgis.ru/wp-content/<wbr>uploads/2016/08/NextGIS-Borsh-<wbr>presentation.pdf</a><br>
><br>
> * GDAL repository adapted for Borsch:<br>
> <a href="https://github.com/nextgis-borsch/lib_gdal" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch/lib_gdal</a><br>
><br>
> Shortly speaking Borsch is 3 CMake scripts which add ability to include<br>
> dependence library in one line of code.<br>
><br>
> It looks like:<br>
><br>
> find_anyproject(TIFF REQUIRED)<br>
><br>
> Certainly developer can add additional parameter to configure dependency in<br>
> find_anyproject function.<br>
><br>
> Inside  find_anyproject work 2 cases:<br>
><br>
> 1. First of all (by default, but can be overridden) CMake searches host<br>
> system for dependency library (headers and lib files). This is usual CMake<br>
> find_package (<a href="https://cmake.org/cmake/help/v3.0/command/find_package.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/<wbr>v3.0/command/find_package.html</a><wbr>)<br>
> with some additional logic to try different options for hard cases (like<br>
> Qt).<br>
><br>
> 2. If library not found, find_anyproject can get the sources or prebuild<br>
> library from github.<br>
><br>
> So the GDAL or any other library can be build the normal way, but developer<br>
> have additional features to configure build all libraries with one compiler<br>
> and one set of compiler/linker settings (with some limits). Such way we can<br>
> have rather complicated scenarios to build GDAL and dependencies.<br>
><br>
> Here it is several examples of benefits of this approach:<br>
><br>
> 1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library for<br>
> iOS as *.framework and for Android as *.so (arm7, arm64, i386, x86_64<br>
> architecture). I build all dependencies include GDAL statically and link in<br>
> one fat library. The all code that do it:<br>
> <a href="https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236" rel="noreferrer" target="_blank">https://github.com/nextgis/<wbr>nextgis_datastore/blob/master/<wbr>cmake/extlib.cmake#L118-L236</a><br>
><br>
> By the way the library also builds on Linux and Mac OS (Windows under<br>
> development) and CMake try to use existed in host system libraries. If CMake<br>
> find GDAL in host system it will use it and all (-DENABLE_PLSCENES=OFF ... )<br>
> will be ignored as it already build with another parameters.<br>
><br>
> 2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa:<br>
> <a href="https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules" rel="noreferrer" target="_blank">https://github.com/nextgis/<wbr>ppa/blob/master/gdal/master/<wbr>debian/rules</a><br>
><br>
> 3. Build QGIS<br>
> (<a href="https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149" rel="noreferrer" target="_blank">https://github.com/nextgis/<wbr>nextgisqgis/blob/master/<wbr>CMakeLists.txt#L149</a>),<br>
> PostGIS<br>
> (<a href="https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch/postgis/blob/master/<wbr>CMakeLists.txt#L165</a>),<br>
> Formbuilder<br>
> (<a href="https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173" rel="noreferrer" target="_blank">https://github.com/nextgis/<wbr>formbuilder/blob/master/cmake/<wbr>extlib.cmake#L53-L173</a>)<br>
><br>
> This is main Borsch features.<br>
><br>
><br>
> There are some additional conventions like:<br>
><br>
>     * I modify all libraries included into Borsch repository to install on<br>
> unix-like paths. For Linux this is usual, for Windows and Mac OS this let us<br>
> to use Qt installer framework an install software mach similar like on<br>
> Linux. This is about target "install" which is vary on different libraries<br>
> (CMake has it own conventions about it). This is not mandatory for Borsch<br>
> itself but useful. CMake can register installed libraries in system<br>
> repository to simplify find them in find_package function.<br>
><br>
>     * CMake get library version from sources in all libraries included into<br>
> Borsch (if applicable, otherwise set it in CMake script). This is necessary<br>
> if exact version of library needed. This is not mandatory. One more benefit<br>
> during building process we can see dependency library version in console.<br>
><br>
>     * We modify all libraries included into Borsch repository to find<br>
> dependencies using find_anyproject. It is simple to use libraries from our<br>
> borsch repository, but developer can fork them or use any other sources and<br>
> build systems to have dependency library in it's host system.<br>
><br>
> One can see this is all very flexible.<br>
><br>
><br>
> What about GDAL.<br>
><br>
> 1. After unification GDALDataset and OGRDatasource current sources tree is<br>
> not fit for this new logic of GDAL classes. I rearranged sources more closer<br>
> to GDAL classes and CMake needs. Main changes are moving raster and vector<br>
> drivers inside drivers folder<br>
> (<a href="https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers).This" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch/lib_gdal/tree/master/<wbr>drivers).This</a><br>
> simplify situation where different drivers need the same dependency library<br>
> (libpg, libsqlite, etc.). Also there are several raster/vector drivers which<br>
> need a separate directory but now presented in ogr or frmts directories.<br>
> There are some bad decisions I made - for example I moved unit tests into<br>
> separate repository - this was a mistake. We will return unit tests back to<br>
> GDAL repository.<br>
><br>
> An example of cmake friendly way see<br>
> <a href="https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch/lib_gdal/blob/master/<wbr>drivers/vector/CMakeLists.txt</a>.<br>
> The driver developer must only create new folder and put CMakeLists.txt file<br>
> into it. The upper CMake script will find new driver and add it to GDAL<br>
> build. In common cases no need to modify upper CMake scripts.<br>
><br>
> 2. I remove third-party code from drivers folders (TIFF, GeoTIF, PNG, JPEG<br>
> etc). All this code are in separate repositories. I don't see the difference<br>
> to get this code from git pull from main GDAL repository or from the<br>
> separate repository via find_anyproject process. Current GDAL repository<br>
> looks like the <a href="https://github.com/nextgis-borsch" rel="noreferrer" target="_blank">https://github.com/nextgis-<wbr>borsch</a> packed in one repository.<br>
><br>
><br>
> In conclusion:<br>
><br>
> 1. Borsch added flexible and useful features and not remove existing<br>
> approach<br>
><br>
> 2. The current cmaked GDAL are in production in my company more than a year<br>
> on Windows, Linix, Mac OS, iOS, Android.<br>
><br>
> 3. I'm ready to discuss and improve current solution. Any help are welcome<br>
><br>
> 4. I also will be happy to contribute directly or via PR into GDAL trunk<br>
> instead of backporting in both directions improvements that we do in GDAL .<br>
><br>
><br>
> Finally:<br>
><br>
> Find the link to page with the CMake in GDAL discussion -<br>
> <a href="https://trac.osgeo.org/gdal/wiki/CMake" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>wiki/CMake</a><br>
><br>
> --<br>
> Best regards,<br>
>     Dmitry<br>
><br>
><br>
</div></div><span class="im HOEnZb">> ______________________________<wbr>_________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a><br>
<br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Alexander Bruy<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div></div></div>