octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: install location of Octave libraries in .debs


From: Michael Creel
Subject: Re: install location of Octave libraries in .debs
Date: Wed, 15 Sep 2004 16:52:14 +0200
User-agent: KMail/1.7

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:
> address@hidden:~> 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 <address@hidden>
>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]