[gdal-dev] About CMake build again

[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.

-- 
Alexander Bruy