<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>As Even said it make sense to move discussion from this ticket
(<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/7080">https://trac.osgeo.org/gdal/ticket/7080</a>) to the list.</p>
<p>First of all I would like to make small introduction to Borsch
project. Here it is some useful links:<br>
</p>
<blockquote>
<p>* Borsch repository: <a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/borsch">https://github.com/nextgis-borsch/borsch</a></p>
<p>* Presentation on FOSS4G 2016:
<a class="moz-txt-link-freetext" href="http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf">http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf</a></p>
<p>* GDAL repository adapted for Borsch:
<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal">https://github.com/nextgis-borsch/lib_gdal</a></p>
</blockquote>
<p>Shortly speaking Borsch is 3 CMake scripts which add ability to
include dependence library in one line of code.</p>
<p>It looks like:</p>
<p>find_anyproject(TIFF REQUIRED)</p>
<p>Certainly developer can add additional parameter to configure
dependency in find_anyproject function. <br>
</p>
<p>Inside find_anyproject work 2 cases:</p>
<p>1. First of all (by default, but can be overridden) CMake
searches host system for dependency library (headers and lib
files). This is usual CMake find_package
(<a class="moz-txt-link-freetext" href="https://cmake.org/cmake/help/v3.0/command/find_package.html">https://cmake.org/cmake/help/v3.0/command/find_package.html</a>) with
some additional logic to try different options for hard cases
(like Qt).</p>
<p>2. If library not found, find_anyproject can get the sources or
prebuild library from github.<br>
</p>
<p>So the GDAL or any other library can be build the normal way, but
developer have additional features to configure build all
libraries with one compiler and one set of compiler/linker
settings (with some limits). Such way we can have rather
complicated scenarios to build GDAL and dependencies. <br>
</p>
<p>Here it is several examples of benefits of this approach: <br>
</p>
<p>1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one
library for iOS as *.framework and for Android as *.so (arm7,
arm64, i386, x86_64 architecture). I build all dependencies
include GDAL statically and link in one fat library. The all code
that do it:
<a class="moz-txt-link-freetext" href="https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236">https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236</a></p>
<p>By the way the library also builds on Linux and Mac OS (Windows
under development) and CMake try to use existed in host system
libraries. If CMake find GDAL in host system it will use it and
all (<span style="color: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 251, 221); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">-DENABLE_PLSCENES=</span><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73); font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">OFF ... )</span>
will be ignored as it already build with another parameters.</p>
<p>2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa:
<a class="moz-txt-link-freetext" href="https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules">https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules</a></p>
<p>3. Build QGIS
(<a class="moz-txt-link-freetext" href="https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149">https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149</a>),
PostGIS
(<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165">https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165</a>),
Formbuilder
(<a class="moz-txt-link-freetext" href="https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173">https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173</a>)</p>
<p>This is main Borsch features. <br>
</p>
<p><br>
</p>
<p>There are some additional conventions like:</p>
<p> * I modify all libraries included into Borsch repository to
install on unix-like paths. For Linux this is usual, for Windows
and Mac OS this let us to use Qt installer framework an install
software mach similar like on Linux. This is about target
"install" which is vary on different libraries (CMake has it own
conventions about it). This is not mandatory for Borsch itself but
useful. CMake can register installed libraries in system
repository to simplify find them in find_package function.<br>
</p>
<p> * CMake get library version from sources in all libraries
included into Borsch (if applicable, otherwise set it in CMake
script). This is necessary if exact version of library needed.
This is not mandatory. One more benefit during building process we
can see dependency library version in console.<br>
</p>
<p> * We modify all libraries included into Borsch repository to
find dependencies using find_anyproject. It is simple to use
libraries from our borsch repository, but developer can fork them
or use any other sources and build systems to have dependency
library in it's host system.</p>
<p>One can see this is all very flexible.</p>
<p><br>
</p>
<p>What about GDAL.</p>
<p>1. After unification GDALDataset and OGRDatasource current
sources tree is not fit for this new logic of GDAL classes. I
rearranged sources more closer to GDAL classes and CMake needs.
Main changes are moving raster and vector drivers inside drivers
folder
(<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers">https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers</a>).This
simplify situation where different drivers need the same
dependency library (libpg, libsqlite, etc.). Also there are
several raster/vector drivers which need a separate directory but
now presented in ogr or frmts directories. There are some bad
decisions I made - for example I moved unit tests into separate
repository - this was a mistake. We will return unit tests back to
GDAL repository. <br>
</p>
<p>An example of cmake friendly way see
<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt">https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt</a>.
The driver developer must only create new folder and put
CMakeLists.txt file into it. The upper CMake script will find new
driver and add it to GDAL build. In common cases no need to modify
upper CMake scripts. <br>
</p>
<p>2. I remove third-party code from drivers folders (TIFF, GeoTIF,
PNG, JPEG etc). All this code are in separate repositories. I
don't see the difference to get this code from git pull from main
GDAL repository or from the separate repository via
find_anyproject process. Current GDAL repository looks like the
<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch">https://github.com/nextgis-borsch</a> packed in one repository. <br>
</p>
<p><br>
</p>
<p>In conclusion:</p>
<p>1. Borsch added flexible and useful features and not remove
existing approach</p>
<p>2. The current cmaked GDAL are in production in my company more
than a year on Windows, Linix, Mac OS, iOS, Android.<br>
</p>
<p>3. I'm ready to discuss and improve current solution. Any help
are welcome</p>
<p>4. I also will be happy to contribute directly or via PR into
GDAL trunk instead of backporting in both directions improvements
that we do in GDAL .</p>
<p><br>
</p>
<p>Finally:</p>
<p>Find the link to page with the CMake in GDAL discussion -
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/wiki/CMake">https://trac.osgeo.org/gdal/wiki/CMake</a><br>
</p>
<pre class="moz-signature" cols="72">--
Best regards,
Dmitry</pre>
</body>
</html>