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

[Sean Gillies]

On Sun, May 28, 2023 at 2:14 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi Sean,
>
>
> Using the CMake files as a source of truth helps. But they don't describe
> everything. For example, they don't explain that GDAL needs libhdf5 to be
> built with special features. That one stumped me for a while. I was seeing
> a build message like "HDF5 not detected (found version 1.12.1)". I finally
> found the clue in the vcpkg repo.
>
> ==> https://gdal.org/development/building_from_source.html#hdf5: "The
> HDF5 CXX library is needed for the KEA
> <https://gdal.org/drivers/raster/kea.html#raster-kea> driver."
>
> That said, it isn't obvious to realize that detection of HDF5 fails
> because of that. That's a bit of a downside with CMake FindXXXX modules
> whose output isn't always very helpful.
>
> Actually, I've changed the logic in
> https://github.com/OSGeo/gdal/pull/7851 to only check for HDF5 CXX if we
> have found libkea before. That reduces the requirements to what is really
> needed.
>
Thank you!

>
> Also, the CMake files don't explain that the GDAL MBTiles driver depends
> on the OGR MVT driver.
>
> Also fixed per https://github.com/OSGeo/gdal/pull/7851.  It is easy to
> miss capturing such dependencies to a driver that is built-in by default
>
> Even
>
Is MVT really a default driver? In
https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/CMakeLists.txt#L80
it looks like it has library and driver dependencies. And anyway, its
dependencies were met in my build script. It should have been discovered if
it was a default driver?

Testing build systems is tough. I know GDAL can't test that all optional
drivers can be configured and built in isolation. At the same time,
profiles of drivers between the bare minimum and
everything-but-the-kitchen-sink are useful to some communities of users,
like the projects that would like to "pip install rasterio" in their own
builds. I resented being told on this list (not by you, Even) that I could
take it or leave it with regards to the current build situation. For my
part, I can do a better job of trying rasterio wheel builds against the
upcoming versions of GDAL, and I will do so.


>
>
> On Mon, May 22, 2023 at 8:53 AM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Hi Sean,
>>
>> I presume you got this because you defined OGR_BUILD_OPTIONAL_DRIVERS=OFF
>> which then cause OGR_ENABLE_DRIVER_AVC to be set to OFF.
>>
>> We already a quite overwhelming amount of documentation in
>> https://gdal.org/development/building_from_source.html about all the
>> existing variables, and I'm not sure adding an exhaustive list of all the
>> inter driver dependencies will be user-digestable and could rot easily.
>>
>> That said in https://github.com/OSGeo/gdal/pull/7806 I've tried to
>> improve the current error message with a hint for the reason for the error
>> and the (likely) reason for it to happen.
>>
>> I've also added pointers in the doc page to the CMakeLists.txt files
>> where the dependencies are expressed. Hopefully people who are in the
>> business of making custom GDAL builds can make sense of that.
>>
>> Even
>> Le 20/05/2023 à 01:26, Sean Gillies a écrit :
>>
>> Hi all,
>>
>> I really appreciate the documentation at
>> https://gdal.org/development/building_from_source.html. But there are
>> gaps. For example, today I ran into
>>
>> CMake Error at cmake/helpers/GdalDriverHelper.cmake:331 (message):
>> GDAL_ENABLE_DRIVER_AIGRID cannot be enabled because condition
>> OGR_ENABLE_DRIVER_AVC is not met. To ignore this error (but the driver
>> will not be built), set the GDAL_IGNORE_FAILED_CONDITIONS variable
>>
>> This dependence isn't documented. It's a bit frustrating to work through
>> missing directives one at a time when adding new drivers to my build.
>>
>> Is it possible for a driver's dependencies to be enabled when I enable a
>> driver?
>>
>> If not, can we consider using GDAL maintenance funding and resources on
>> documenting the heck out of this system?
>>
>>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230528/aa079639/attachment.htm>