Re: octave-forge build rules for debian

[John W. Eaton]

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

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

I don't see why the directories that have version numbers need to be
changed.  They are intended for files that belong to a specific
version of Octave and the API for a specific version is fixed.

It might be useful to subdivide the version-independent directories
using the API version.  Certainly for the .oct files and perhaps even
for the .m files as they may also be affected by changes in the
interface for various built-in functions or even other .m files.

So, would that be useful?  We could have

  $libexecdir/octave/site/oct/$API/$canonical_host_type

I'm not sure exactly where the $API should be inserted here, but
after site/oct keeps site/oct and site/exec at the same level.

For .m files we could have

  $datadir/octave/site/$API/m

in addition to

  $datadir/octave/site/m

where one could keep files that really are independent of the Octave
version.

I don't see that there needs to be an API-independent site/oct
directory since those files would not load anyway.`

I also don't see that there needs to be an API-specific directory for
exec files since those are external programs that should not be
affected by changes in Octave's internal API.

Good idea or too much additional complexity?

jwe