[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave-forge build rules for debian
From: |
Rafael Laboissiere |
Subject: |
Re: octave-forge build rules for debian |
Date: |
Tue, 8 Jul 2003 15:24:57 -0500 |
User-agent: |
Mutt/1.5.4i |
* 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