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....@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
