<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 28, 2023 at 2:14 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Hi Sean,<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<p>==>
<a href="https://gdal.org/development/building_from_source.html#hdf5" target="_blank">https://gdal.org/development/building_from_source.html#hdf5</a>: "The
HDF5 CXX library is needed for the <a href="https://gdal.org/drivers/raster/kea.html#raster-kea" target="_blank"><span>KEA</span></a> driver."</p>
<p>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.</p>
<p>Actually, I've changed the logic in
<a href="https://github.com/OSGeo/gdal/pull/7851" target="_blank">https://github.com/OSGeo/gdal/pull/7851</a> to only check for HDF5 CXX
if we have found libkea before. That reduces the requirements to
what is really needed.<br></p></div></blockquote><div>Thank you! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Also, the CMake files don't explain that the GDAL MBTiles
driver depends on the OGR MVT driver.</div>
</div>
</div>
</blockquote>
<p>Also fixed per <a href="https://github.com/OSGeo/gdal/pull/7851" target="_blank">https://github.com/OSGeo/gdal/pull/7851</a>. It is
easy to miss capturing such dependencies to a driver that is
built-in by default</p>
<p>Even<br></p></div></blockquote><div>Is MVT really a default driver? In <a href="https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/CMakeLists.txt#L80">https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/CMakeLists.txt#L80</a> 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?</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, May 22, 2023 at
8:53 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Sean,</p>
<p>I presume you got this because you defined
OGR_BUILD_OPTIONAL_DRIVERS=OFF which then cause <span><span>
OGR_ENABLE_DRIVER_AVC to be set to OFF.</span></span></p>
<p><span><span>We already a quite overwhelming amount of
documentation in <a href="https://gdal.org/development/building_from_source.html" target="_blank">https://gdal.org/development/building_from_source.html</a>
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.<br>
</span></span></p>
<p><span><span>That said in </span></span><a href="https://github.com/OSGeo/gdal/pull/7806" target="_blank">https://github.com/OSGeo/gdal/pull/7806</a>
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. <br>
</p>
<p>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.<br>
</p>
<p>Even<br>
</p>
<div>Le 20/05/2023 à 01:26, Sean Gillies a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>I really appreciate the documentation at <a href="https://gdal.org/development/building_from_source.html" target="_blank">https://gdal.org/development/building_from_source.html</a>.
But there are gaps. For example, today I ran into <br>
</div>
<div><br>
</div>
<div>
<div>
<div><span> <span>CMake Error at
cmake/helpers/GdalDriverHelper.cmake:331
(message): </span></span> </div>
</div>
<div>
<div> </div>
</div>
<div>
<div> <span> <span> GDAL_ENABLE_DRIVER_AIGRID
cannot be enabled because condition </span></span>
</div>
</div>
<div>
<div> </div>
</div>
<div>
<div> <span> <span> OGR_ENABLE_DRIVER_AVC is not
met. To ignore this error (but the driver </span></span>
</div>
</div>
<div>
<div> </div>
</div>
<span> <span> will not be built), set the
GDAL_IGNORE_FAILED_CONDITIONS variable</span></span></div>
<div><span><span><br>
</span></span></div>
<div><span><span>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.<br>
</span></span></div>
<div><span><span><br>
</span></span></div>
<div><span><span>Is it possible for </span></span>a
driver's dependencies to be enabled when I enable a
driver?</div>
<div><br>
</div>
<div>If not, can we consider using GDAL maintenance
funding and resources on documenting the heck out of
this system?<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div></blockquote></div>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div></div>