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

 
 

bug #43180: remove hdf5 from Octave public API

Submitted by:  Mike Miller <mtmiller>
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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:

http://hg.savannah.gnu.org/hgweb/octave/rev/bfe66db8addb

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:

http://hg.savannah.gnu.org/hgweb/octave/rev/09ed6f7538dd

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

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

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