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