bugGNU Octave - Bugs: bug #43180, remove hdf5 from Octave public API


bug #43180: remove hdf5 from Octave public API

Submitter:  Mike Miller <mtmiller>
Submitted:  Tue 09 Sep 2014 05:40:02 PM UTC
Category:  Libraries Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Fri 18 Nov 2016 08:53:59 PM UTC, comment #4: 

I think this is done in 4.2.0.

Mike Miller <mtmiller>
Project Administrator
Mon 15 Jun 2015 09:47:55 PM UTC, comment #3: 

I pushed another change to further isolate hdf5.h and HDF5 typedefs:


John W. Eaton <jwe>
Project Administrator
Fri 27 Feb 2015 02:19:47 AM UTC, comment #2: 

This is a good step in the right direction. There are still HAVE_HDF5 conditionals but not in any header files. And hdf5.h is only included via oct-hdf5.h (and ls-hdf5.h transitively).

Mike Miller <mtmiller>
Project Administrator
Thu 26 Feb 2015 05:14:37 PM UTC, comment #1: 

I pushed this change:


I think it solves the immediate problem.  Ultimately, I'd like to isolate all the HAVE_HDF5 conditionals in just a few files.  That means making the load_hdf5 and save_hdf5 functions in the octave_value classes unconditionally call functions that deal with HDF5 being available (or not) and placing all the HDF5 interface glue in those functions instead of the octave_value classes.

John W. Eaton <jwe>
Project Administrator
Tue 09 Sep 2014 05:40:02 PM UTC, original submission:  

The Octave API should not depend on HDF5 include files, functions, or types. Octave's use of HDF5 is an internal implementation detail and users of the Octave libraries shouldn't have to see that. It's only really needed for Octave's load and save functions and for octave_value-derived objects to be able to serialize/deserialize themselves to HDF5-format files.

I looked at this about a month ago and this seemed possible. It would require recategorizing some header files as private, not to be installed as part of the public API, and it would require declaring our own version of HDF5's hid_t (which is just an integer) or using an opaque wrapper for an hid_t instead. I'm assigning myself, but help, patches, or testing welcome.

Mike Miller <mtmiller>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-18 mtmiller StatusPostponed Fixed
        Open/ClosedOpen Closed
    2015-02-27 mtmiller StatusNone Postponed
        Assigned tomtmiller None
    2014-09-09 mtmiller Dependencies- bugs #38928 is dependent

    Back to the top

    Powered by Savane 3.9