<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Alexander,</p>
<p>Please read carefully that I wrote before. There are 3 options:</p>
<blockquote>
<p>1. Build gdal with all dependencies getting them from github
(WITH_EXTERNAL). Preferable for Windows
<br>
<br>
2. Build gdal using the system libraries. Preferable for Linux
<br>
<br>
3. Build gdal using the dependency libraries build by user (out
of source) and registered in CMake package registry. This is I
use now. This script help me to clone all libraries, build them
and register them in CMake package registry (<a
class="moz-txt-link-freetext"
href="https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134">https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134</a>).
<br>
</p>
<p><br>
</p>
</blockquote>
<p>Again, this is the options which one can choose. So if building
everything from scratch not suits you - just select another
option. I introduce presets (now there is only one for option 1 -
<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal/issues/14">https://github.com/nextgis-borsch/lib_gdal/issues/14</a>) and this can
be expanded for different scenarios. If you need full control on
build just provide command line options to CMake and get what you
need.<br>
</p>
<p>My fast code review solution of Hiroshi shows that it very far
from working solution and need much work that already done in
lib_gdal from Borsch. <br>
</p>
<p>My opinion is that different options is much flexible and suits
for many scenarios as very limited solution from
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/7080">https://trac.osgeo.org/gdal/ticket/7080</a>. <br>
</p>
<pre class="moz-signature" cols="72">Best regards,
Dmitry</pre>
<div class="moz-cite-prefix">29.10.17 9:11, Alexander Bruy пишет:<br>
</div>
<blockquote type="cite"
cite="mid:CALuHMPD1W0picmMy38Jz_8fEvGYDtaX2C_NCDrv5YSKNQo9RbQ@mail.gmail.com">
<pre wrap="">While I'm not GDAL developer or regular contributor (submitted only
few patches),
but still often build GDAL trunk on WIndows and Linux, and less often on Mac.
Personally I think that solution proposed in
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/7080">https://trac.osgeo.org/gdal/ticket/7080</a>
is more preferable. It does not require *all* dependencies to be build
with cmake,
it does not require maintaining forks with special directory structure for *all*
dependencies, it plays well with conventions/packages provided on all systems
out of the box. Maybe borsch is good for in-house use when all stack
is build from
scratch but it is not suitable for real-world use cases.
Of course, #7080 is not ideal, there are some issues, but as I understand the
work is not over and most (if not all) issues can be solved.
Just my 2c.
2017-10-28 0:06 GMT+03:00 Dmitry Baryshnikov <a class="moz-txt-link-rfc2396E" href="mailto:bishop.dev@gmail.com"><bishop.dev@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
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.
First of all I would like to make small introduction to Borsch project. Here
it is some useful links:
* Borsch repository: <a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/borsch">https://github.com/nextgis-borsch/borsch</a>
* 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>
* 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>
Shortly speaking Borsch is 3 CMake scripts which add ability to include
dependence library in one line of code.
It looks like:
find_anyproject(TIFF REQUIRED)
Certainly developer can add additional parameter to configure dependency in
find_anyproject function.
Inside find_anyproject work 2 cases:
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).
2. If library not found, find_anyproject can get the sources or prebuild
library from github.
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.
Here it is several examples of benefits of this approach:
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>
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 (-DENABLE_PLSCENES=OFF ... )
will be ignored as it already build with another parameters.
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>
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>)
This is main Borsch features.
There are some additional conventions like:
* 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.
* 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.
* 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.
One can see this is all very flexible.
What about GDAL.
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.
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.
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.
In conclusion:
1. Borsch added flexible and useful features and not remove existing
approach
2. The current cmaked GDAL are in production in my company more than a year
on Windows, Linix, Mac OS, iOS, Android.
3. I'm ready to discuss and improve current solution. Any help are welcome
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 .
Finally:
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>
--
Best regards,
Dmitry
_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>