[gdal-dev] About CMake build again

Sat Oct 28 23:11:33 PDT 2017

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
https://trac.osgeo.org/gdal/ticket/7080
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 <bishop.dev at gmail.com>:
> Hi,
>
> As Even said it make sense to move discussion from this ticket
> (https://trac.osgeo.org/gdal/ticket/7080) to the list.
>
> First of all I would like to make small introduction to Borsch project. Here
> it is some useful links:
>
> * Borsch repository: https://github.com/nextgis-borsch/borsch
>
> * Presentation on FOSS4G 2016:
> http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf
>
> * GDAL repository adapted for Borsch:
> https://github.com/nextgis-borsch/lib_gdal
>
> 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 (https://cmake.org/cmake/help/v3.0/command/find_package.html)
> 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:
> https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236
>
> 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:
> https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules
>
> 3. Build QGIS
> (https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149),
> PostGIS
> (https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165),
> Formbuilder
> (https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173)
>
> 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
> (https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers).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
> https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt.
> 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 https://github.com/nextgis-borsch 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 -
> https://trac.osgeo.org/gdal/wiki/CMake
>
> --
> Best regards,
>     Dmitry
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Alexander Bruy