From octave-maintainers-request at bevo dot che dot wisc dot edu  Thu May 22 03:25:37 1997
Subject: Re: octave version
From: Kurt Hornik <Kurt dot Hornik at ci dot tuwien dot ac dot at>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: Doug Warner <warnerd at trinidad dot cs dot dartmouth dot edu>,         Andreas.Weingessel@ci.tuwien.ac.at,         octave-maintainers@bevo.che.wisc.edu
Date: Thu, 22 May 1997 10:20:04 +0200

>>>>> John W Eaton writes:

> On 21-May-1997, Doug Warner <warnerd at trinidad dot cs dot dartmouth dot edu> wrote:
> | > If someone has the time to look into it, it would be nice if we could
> | > come up with a directory structure that will actually work for people
> | > who want to keep multiple versions installed.  I think the $prefix/lib
> | > and $prefix/include/octave directories are still problems, but there
> | > may be others.
> | 
> | Just using $prefix/lib/octave/$version for the first case would work.

> For 2.1, I've set things up to install the libraries in

>   $libdir/octave-$version

> and to create the following symbolic link in $libdir:

>   octave -> octave-$version

> The link is there so that you can just use (for example)
> -L/usr/local/lib/octave to get the latest version without having to
> remember the version number.

> | To handle the include files, something like
> | $prefix/include/octave-$version/octave/*.h 
> | should be fairly transparent.

> Ok, I did this, along with creating the following symbolic link in
> $includedir ($prefix/include):

>   octave -> octave-$version/octave

> Then you can use

>   #include <octave/foo.h>

> and (for example) -I/usr/local/include to get the latest set of
> headers without having to remember the version number.

It's probably too late now that all changes have already been made, but
I am not too happy about them.

Are we really talking having

	/usr/local/lib/octave-${version}

and /usr/local/lib/octave linked to the one with the highest version
number?  Where will /usr/local/lib/octave/site go then?  What is wrong
about the current layout?  We can always call

	/usr/local/bin/octave-${version}

to get the version we want.

(Besider, why have different versions anyway?  This is probably only of
interest to the developers/testers ...).

The header files are a problem because the typical use is

	#include <octave/something>

right?  John's idea is very nice indeed, and perhaps is the simplest to
support multiple versions for `development'.  (Another idea would be to
have headers in /usr/local/lib/octave/$version/include ...)

> | There's also $prefix/bin/octave-bug, which has version specific info.

> I also added a -$version suffix to octave-bug and mkoctfile for 2.1,
> with links like we currently have for the octave binary itself.

O.k.

> I think the only thing left is the info file.  Since this is used by
> Octave's on-line help system, it really needs to match the version
> that is installed.

> Would people object to creating subdirectories in $infodir?  For example,

>   $infodir/octave-$version

> with the symbolic link

>   $infodir/octave -> octave-$version

> The link could be used so that you wouldn't have to modify your
> $infodir/dir file each time a new version is installed.

Will this really work without any problems?

I think that the `standards' (GNU or e.g. Debian Linux/GNU) speak about
flat info dirs (well, I don't think they explicitly say that one must
not ...).

-k