[gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Alexander,

CMake scripts from #7080 have no logic presented in current building 
system (make/autoconf): there are several mandatory drivers, the 
optional drivers, and drivers depends from other drivers.

Also there is one big problem for me in #7080 - this is third build 
system additionally to GNUMakefile, makefile.vc.  And now CMakeLists.txt 
must be supported too. Three files which must be synced each other with 
and taking into consideration the upper scripts, it's awful!


That about your questions:

1. Now it is not supported. This is really limitations what should gone. 
It can be easily fixed. I thinking on this direction - may be somehow 
like in Carthage project was done (https://github.com/Carthage/Carthage).

2. Here we have 2 cases: 1 - cmaked dependency (we only remove current 
build system with own CMake not touching the original sources), 2 - wrap 
current build system by CMake (see how it is done for Qt4 - 
https://github.com/nextgis-borsch/lib_qt4)

3. This should not be the problem of upstream developers. It may be 
developed some script which periodically get sources and put them to 
cmaked repositories, build and run tests to report if everything is OK. 
Here we can achieve synced releases and developer branches with our owns 
prepared repositories.

4. What about option to get all needed dependencies from github 
(WITH_EXTERNAL) - yes we need own prepared repositories. Theoretical 
there is the mechanism to make direct clone from any repository 
(https://cmake.org/cmake/help/v3.8/module/ExternalProject.html) but 
there are several problems here:

1. Original repository may not support needed platforms (usually Mac OS, 
Android, iOS and Windows) or static/dynamic library builds.

2. No way to uniformly transfer building options to dependency builds.

3. Install paths of original projects may vary and this may be a problem 
in install target of main project. In current solution upper project 
installs all dependency dynamic libraries in it "install" target in 
uniform way.

To solve this problems I choose more simple way to have own prepared 
repositories (again, just like in Carthage approach).


Finally, thanks for your concrete questions!

Best regards,
     Dmitry

30.10.17 10:00, Alexander Bruy пишет:
> Hi Dmitry,
>
> thanks for explanation. I see that there is an option to use system libraries.
> Maybe I'm wrong, but this is also possible with current build system and
> CMake scripts from #7080. There is an option to build deps by myself and
> use them to build GDAL, but again this is also possible with current build
> system and CMake scripts from #7080.
>
> I agree that automatic fetching of missed dependencies is nice feature. And
> can simplify live in some cases. But there are questions:
>
> 1. what if dependency hosted on BitBucket, SourceForge or any self-hosted
> VCS and not in your repository?
> 2. what if dependency use build system different from CMake?
> 3. what if upstream does not want/does not see abny benefits in moving to
> GitHub and/or switching to CMake?
>
> Correct me if I'm wrong, but most of the borsh's benefits require
> changes not only
> in GDAL, but also in all upstream projects, as well as infrastructure
> changes for
> them. Or why you maintain forks for every lib needed by GDAL in your repository?
> If everything is fine and flexible why not use upstream projects directly?
>
> 2017-10-29 15:39 GMT+02:00 Dmitry Baryshnikov <bishop.dev at gmail.com>:
>> 1. Build gdal with all dependencies getting them from github
>> (WITH_EXTERNAL). Preferable for Windows
>>
>> 2. Build gdal using the system libraries. Preferable for Linux
>>
>> 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
>> (https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134).
>>
>> My opinion is that different options is much flexible and suits for many
>> scenarios as very limited solution from
>> https://trac.osgeo.org/gdal/ticket/7080.