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: LibrariesSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 18 Nov 2016 08:53:59 PM UTCmtmillerStatusPostponed=>Fixed
      Open/ClosedOpen=>Closed
    Fri 27 Feb 2015 02:19:47 AM UTCmtmillerStatusNone=>Postponed
      Assigned tomtmiller=>None
    Tue 09 Sep 2014 05:40:28 PM UTCmtmillerDependencies-=>bugs #38928 is dependent

    Back to the top


    Powered by Savane 3.1-cleanup1