Thanks!!! I'm missing HAVE_HDF5. And it looks like I should set HAVE_HDF4
too as I have that in my build too.
The joys of having to maintain a separate build system...
On Thu, Sep 5, 2024 at 1:22 PM Even Rouault <even.roua...@spatialys.com>
wrote:
> Kurt,
>
> Looking at the expected behavior at GDAL's head, I see this. I think it's
> probably fine, but figured I'd ask...
>
> I don't reproduce with master:
>
> $ gdalinfo autotest/gdrivers/data/hdf5/metadata.h5
> Driver: HDF5/Hierarchical Data Format Release 5
> [...]
>
> $ gdalinfo autotest/gdrivers/data/hdf5/u8be.h5
> Driver: HDF5Image/HDF5 Dataset
> [...]
>
>
>
> Is there a reason for the order to be different for the drivers in the
> DEFERRED section compared to the normal driver registration? Does the order
> not matter for DEFERRED?
>
>
> No, that doesn't matter since drivers are re-ordered using the order
> defined in frmts/drivers.ini
>
> But in the netCDF vs HDF5 case, this doesn't matter much since the logic
> in netCDFIdentifyFormat() will skip a HDF5 file if "#ifdef HAVE_HDF5" is
> true and GDALGetDriverByName("HDF5") != nullptr
>
> My guess would be that your build of the netCDF driver lacks -DHAVE_HDF5 .
> By the way I'm thinking this check might be incorrect. This HAVE_HDF5 is if
> libnetcdf has HDF5 support, but in the context of the check if
> GDALGetDriverByName("HDF5") != nullptr, we don't actually care about the
> capabilities of libnetcdf. It is just that if the HDF5 driver is there, we
> should just use it.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
