install location of Octave libraries in .debs

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

install location of Octave libraries in .debs

Michael Creel
Hello Dirk and others,
In the packages for Debian Linux, the symbolic links liboctave.so,
libcruft.so, and liboctinterp.so are created in the
directory /usr/lib/octave-2.1.58 (or whatever the latest version is) rather
than /usr/lib/octave.

When linking against these, you need to know which is the latest version
installed. I'm wondering if the links can be made in /usr/lib/octave, or
using the /etc/alternatives framework, so that one can write a makefile that
will work without knowing the last installed version.

Or, if someone has an easy alternative solution, what is it please?

Regards, Michael


Reply | Threaded
Open this post in threaded view
|

Re: install location of Octave libraries in .debs

Dirk Eddelbuettel
On Wed, Sep 15, 2004 at 03:02:58PM +0200, Michael Creel wrote:

> Hello Dirk and others,
> In the packages for Debian Linux, the symbolic links liboctave.so,
> libcruft.so, and liboctinterp.so are created in the
> directory /usr/lib/octave-2.1.58 (or whatever the latest version is) rather
> than /usr/lib/octave.
>
> When linking against these, you need to know which is the latest version
> installed. I'm wondering if the links can be made in /usr/lib/octave, or
> using the /etc/alternatives framework, so that one can write a makefile that
> will work without knowing the last installed version.
>
> Or, if someone has an easy alternative solution, what is it please?

There is one:

$ man octave-config

which is used for example in all the build scripts I use:
edd@homebud:~> head -16 debian/Octave/octave-forge-2004.09.09/debian/rules
#!/usr/bin/make -f
#                                                       -*- makefile -*-
# debian.rules file for the Debian/GNU Linux octave-forge package
# Copyright 2000 - 2004 by Dirk Eddelbuettel <[hidden email]>

package         = octave-forge
altname         = octave-forge-alternatives
debtmp          := $(CURDIR)/debian/tmp
debdoc          := $(debtmp)/usr/share/doc/$(package)
octdir          := $(shell octave-config --oct-site-dir)
mdir            := $(shell octave-config --m-site-dir)
altoctdir       := $(shell octave-config --oct-site-dir)/$(altname)
altmdir         := $(shell octave-config --m-site-dir | \
                        sed -e +"s,/m$$,,")/$(altname)/m
octbin          := $(shell octave-config -p LOCALVERARCHLIBDIR)
                       
               
The real problem is that we need to rebuild all packages containing .oct
code for every new version. But then that is a price worth paying for new
features -- and there were tons of them lately -- which is somewhat
difficult with a frozen API.  That said, in an ideal world (where John,
David, Paul, ... can all code 36 hrs/day :) it would be nice to undo the
version-numnered paths for, say, a new stable version octave 3.0.

Dirk

--
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx


Reply | Threaded
Open this post in threaded view
|

Re: install location of Octave libraries in .debs

Michael Creel
Thanks,
octave-config -p OCTINCLUDEDIR
gives me just what I wanted.
Michael


On Wednesday 15 September 2004 15:25, Dirk Eddelbuettel wrote:

> On Wed, Sep 15, 2004 at 03:02:58PM +0200, Michael Creel wrote:
> > Hello Dirk and others,
> > In the packages for Debian Linux, the symbolic links liboctave.so,
> > libcruft.so, and liboctinterp.so are created in the
> > directory /usr/lib/octave-2.1.58 (or whatever the latest version is)
> > rather than /usr/lib/octave.
> >
> > When linking against these, you need to know which is the latest version
> > installed. I'm wondering if the links can be made in /usr/lib/octave, or
> > using the /etc/alternatives framework, so that one can write a makefile
> > that will work without knowing the last installed version.
> >
> > Or, if someone has an easy alternative solution, what is it please?
>
> There is one:
>
> $ man octave-config
>
> which is used for example in all the build scripts I use:
> edd@homebud:~> head -16 debian/Octave/octave-forge-2004.09.09/debian/rules
> #!/usr/bin/make -f
> #                                                       -*- makefile -*-
> # debian.rules file for the Debian/GNU Linux octave-forge package
> # Copyright 2000 - 2004 by Dirk Eddelbuettel <[hidden email]>
>
> package         = octave-forge
> altname         = octave-forge-alternatives
> debtmp          := $(CURDIR)/debian/tmp
> debdoc          := $(debtmp)/usr/share/doc/$(package)
> octdir          := $(shell octave-config --oct-site-dir)
> mdir            := $(shell octave-config --m-site-dir)
> altoctdir       := $(shell octave-config --oct-site-dir)/$(altname)
> altmdir         := $(shell octave-config --m-site-dir | \
>                         sed -e +"s,/m$$,,")/$(altname)/m
> octbin          := $(shell octave-config -p LOCALVERARCHLIBDIR)
>
>
> The real problem is that we need to rebuild all packages containing .oct
> code for every new version. But then that is a price worth paying for new
> features -- and there were tons of them lately -- which is somewhat
> difficult with a frozen API.  That said, in an ideal world (where John,
> David, Paul, ... can all code 36 hrs/day :) it would be nice to undo the
> version-numnered paths for, say, a new stable version octave 3.0.
>
> Dirk