[gdal-dev] Improving details of the project build system and/or documentation

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

some thoughts on the thoughts from a packaging viewpoint.

> - you definitely don't want to build all drivers (that can be built as
>   plugins) as plugins. This works (this is actually my dev setup, to
>   ensure that the core exports all the symbols needed for drivers
>   built as plugins), but I've found there's a measurable penalty in
>   doing so (300 ms to load the 127 plugins on my system, ie each GDAL
>   command line invokation will at least take 300 ms, which might be a
>   significant penalty in some workflows) . So
>   GDAL_ENABLE_PLUGINS_NO_DEPS=YES (cf
>   https://gdal.org/development/building_from_source.html#cmdoption-arg-GDAL_ENABLE_PLUGINS_NO_DEPS-BOOL)
>   is typically discouraged.  But 10 or so plugins should be fine.

Would it be reasonable to only load the plugins that will be used?  I
would think most invocations only use a few formats.

> - by free-standing CMake project, what do you mean ? Couldn't that
>   just the existing frmts/XXXX/CMakeLists.txt file that would detect
>   it is called as the top level CMakeLists.txt (probably by checking
>   ${CMAKE_CURRENT_SOURCE_DIR} == ${PROJECT_SOURCE_DIR}) and then
>   change its logic to find libgdal and its dependencies ? And users
>   would "cmake -S frmts/XXXX -B plugin_XXXX" to configure just for
>  that plugin.

>From the packaging point of view, I want one package which is core, and
another package for each plugin that has dependencies that I think
someone would reasonably want to avoid.  I would like to maintain a
Makefile.common with version and some of this, if these are released as
part of a gdal release and just built separately.  If the plugin is
truly separate (separate release schedule), then it is cleanly its own
package.

It is not ok to say "build everything and then pick out files for
different packages".  That sort of works in some systems, and not
others, and it only works in systems where the assumption is some giant
system builds once for everybody and users never compile anything.  The
point is to avoid having to install and build from source the difficult
dependencies.

> - we would need to keep the current monolithic CMake project approach
>   working, at the very least for people doing static builds, but even
>   for people doing dynamic builds as it might be still be more
>   practical if you can install all the dependencies at once. Having
>   the standalone capability in addition would be an extra complexity,
>   so we need to be sure it addresses real use cases, and perhaps
>   restrict it to a few select drivers. Obvious candidates for
>   standalone CMake projects would likely be for the few drivers that
>   have proprietary dependencies (ECW, JP2KAK, MrSID, Oracle, ...) and
>  aren't shipped by FOSS binary distributions.

(I don't follow 'and'; surely no FOSS binary distribution could have any
of these??)

I don't see why one couldn't still build plugins and just have one build
build them all.

It's not just proprietary things (which definitely need to be
separable), but big things.  One might want to avoid the pgsql driver,
for example, in the core gdal package that might just do geopackage and
geojson.  But maybe GIS and small just don't go together (and I say that
more or less seriously).

> - offering the possibility of building just a driver as a plugin in a
>   unit way would require people to build against the same GDAL headers
>   as libgdal. So people would have to download the same version of the
>   GDAL sources as the one used by the libgdal provided by rasterio +
>   having the required SDK + installing the libs of the SDK in a path
>   where Python/rasterio can find them. Is it in the expected cultural
>   background of rasterio users to do that on their own ?

Absolutely they have to and that's fine.  The headers should be
installed with the library and they should be used when plugins are
built.  There is no other sane path.  So that either means "just include
the headers in the gdal lib package" or "have gdal-core and
gdal-core-devel (or whatever FooOS calls it) packages that have the libs
and the headers respectively".  This is really no different from any
package that depends on any lib.