[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave version
From: |
Kurt Hornik |
Subject: |
Re: octave version |
Date: |
Thu, 22 May 1997 10:20:04 +0200 |
>>>>> John W Eaton writes:
> On 21-May-1997, Doug Warner <address@hidden> 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
Re: octave version, John W. Eaton, 1997/05/21