Re: octave-forge build rules for debian

[John W. Eaton]

[In a discussion off the list, Dirk asked about defining a separate API
version number that could be used in place of the Octave version
number for checking to see whether a .oct file could (or should) be
loaded. --jwe]

On  8-Jul-2003, Rafael Laboissiere <address@hidden> wrote:

| * John W. Eaton <address@hidden> [2003-07-08 13:11]:
| 
| > No, I think you have it right.  We could do this.  The major cost is
| > making sure we increment the API version number when a change is made
| > that could affect the way internals work.  Maybe keeping up with this
| > kind of thing would not be so difficult now.
| 
| This is definitively a very nice improvement to Octave and I would be
| pleased to see it implemented.

OK, for now OCTAVE_API_VERSION is defined in version.h, and it is just
a single integer (in a string).  The comparison in check_version (in
src/defun.cc) is just to see if the version passed to check_version
(compiled into the .oct file) is the same as the one in the Octave
binary.  If not, an error message is issued and the function from the
.oct file is not loaded.  I think that is good enough.  The API
version number will be incremented if there are changes to the
internals that would cause a .oct file to fail.  This would mean any
changes in argument lists for functions, etc.  New functions would be
OK, I suppose.  The one problem I see that might make the API version
a bit less useful is that because the internals of Octave are all
available to any .oct file, almost any internal interface change could
cause trouble, so that may mean incrementing the API version almost as
frequently as the version number is incremented.  Perhaps it is time
to get serious about defining an API that users can rely on.

jwe