[Octave-bug-tracker] [bug #38928] configure -> hdf5 doesn't handle path through

[Mike Miller]

Follow-up Comment #15, bug #38928 (project octave):

Yes, adding either HDF5_CPPFLAGS or ALL_CPPFLAGS gets past that one rule.
There are other specific *.df rules in libinterp/*/module.mk that also need
HDF5_CPPFLAGS added. And there are sources, e.g. builtins.cc, octave.cc,
libgui/src, libgui/graphics, that also need it. I can try to iteratively go
through and add it to the minimal number of rules that need it.

At the extreme opposite end, would it be a terrible thing to define our own
"hid_t" type, it's only an int? Or to be really safe, our own opaque handle
type that would map to an hid_t type? This would potentially remove the need
for HAVE_HDF5 and hdf5.h to be in any public header files. From an
encapsulation point of view this would be a win, it would be far better for
users to not even have to see this conditional and depend on these third-party
header files.

Of course now that I'm chasing which files include other files, this implies
massively cleaning up the set of files installed in the include directory, I
believe there are many files installed that don't need to be, for example
ls-*.h, ov-*.cc. The ls-hdf5.h header file contains calls to HDF5 functions,
but it is never needed by any external user of Octave.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38928>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/