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

[dg0yt at darc.de]

Even,

I understand the downsides and agree with everything you say.

I work with the static builds because this is what is tested in vcpkg CI for macOS and Linux. For Windows, there are also dynamic builds in CI. Dynamic options for Linux and macOS exist but aren't tested, so I guess some of gdal's  dependencies won't build.
Also, vcpkg doesn't aim to offer a binary "distribution" of tools for users but is focused on libraries for developers, built from source.

Kai

> Even Rouault <even.rouault at spatialys.com> hat am 11.02.2022 13:15 geschrieben:
> 
>  
> 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.