Am 13.02.24 um 08:18 schrieb Michael Otto via gdal-dev:
I currently use an Ubuntu VM and use an Alpine-Linux Docker container
for compiling. First a static Geos library is created via cmake, then
a static Proj library (without Curl, because this currently leads to
errors) and then Gdal as a static library.
You must consider all transitive dependencies, build them in the right
order, and ensure that transitive link libraries are passed on down to
gdal and to the final app (with link libraries in correct order).
For more than a minimal build, it is really better solved by using
package managers such as vcpkg than by reinventing the wheel - each
dependency may add its own set of problems. A simplified(!) dependency
graph for a minimal build in vcpkg, just gdal core features + geos:
zlib:
libjpeg-turbo:
liblzma:
openssl:
nlohmann-json:
curl[openssl, ssl, non-http]: openssl, zlib
sqlite3[json1, tool]:
tiff[lzma, jpeg, zip]: libjpeg-turbo, liblzma, zlib
proj[tiff, net]: curl, nlohmann-json, sqlite3, tiff
libgeotiff: proj, tiff
json-c:
geos:
gdal: geos, json-c, libgeotiff, proj, tiff, zlib
So libgeotiff, proj, tiff, curl all come with transitive usage
requirements which depend on actual configuration.
This is impossible to reconstruct in CMake find modules (coming with
CMake or GDAL).
In vcpkg, ports (maintainers) ensure that usage requirements are
exported by each package (using CMake config or find module wrappers).
Kai
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
