Re: octave-forge build rules for debian

[Rafael Laboissiere]

* John W. Eaton <address@hidden> [2003-07-08 14:11]:

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

Sounds great.

What I am going to say is quite obvious, but let me say it just for the
record: if the proposal above is implemented, then some path/dir
.oct-related variables in which octave's version number appears (like
octfiledir and localoctfilepath, as returned by octave_config_info) must be
changed to contain instead the API number.

-- 
Rafael