[gdal-dev] cmake status update - 99% good news!

[Even Rouault]

Kai,

there's a point I had in mind regarding your mention of static builds 
but forgot to mention. I consider GDAL static builds as inferior in term 
of capabilities compared to dynamic builds because:

- they don't allow to have GDAL drivers built as plugins : due to the 
design of GDAL drivers, plugins need to link against libgdal. You don't 
want each plugin to have its copy of libgdal. At runtime I'm not sure 
how that would behave regarding the multiple instances of the same GDAL 
symbols.

- and I don't believe you can build Python bindings against as static 
libgdal because we have several Python modules (gdal, ogr, osr, 
gdal_array) with each linking to libgdal. So if you ever managed to make 
them build, at runtime you'd get again several copies of the GDAL symbols

Without mentioning the size of the GDAL binaries with each of them 
embedding libgdal.

So even if I understand there are use cases for GDAL static builds 
(thanks for all the work you do on that side with your pull requests !), 
having them as the default in a distribution seems problematic to me.

Even

Le 25/01/2022 à 08:23, Kai Pastor, DG0YT a écrit :
> I made an initial attempt on gdal with cmake for vcpkg: 
> https://github.com/microsoft/vcpkg/pull/22392
>
> Now vcpkg's default is static linkage on Linux and macOS. AFAICT 
> static linkage is not covered very well. Fixing this needs a lot of 
> work either on the find modules, or on getting dependencies to provide 
> exported config. In some cases (e.g. GEOS), config files already 
> exist, but they are neither used nor a drop-in replacement (target 
> names differ).
>
> On the export side, all custom find modules must be made available to 
> the exported configuration if not burning the depended-on libraries 
> into the exported cmake config. Generating a complete gdal.pc needs 
> work, too. CMake doesn't provide any help ATM. (But note 
> https://gitlab.kitware.com/cmake/cmake/-/issues/22621.)
>
> This is not meant as an argument against shortening the release 
> schedule for cmake. I just want to underline that the CMake build 
> system will continue to need significant changes, including 
> user-facing changes.
>
> Kai Pastor
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.