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

[Even Rouault]

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.

>
> 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

>
>
> 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
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230528/6fd2cd68/attachment-0001.htm>