[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Distribution-specific include paths for several versions of Octave
From: |
Thomas Weber |
Subject: |
Re: Distribution-specific include paths for several versions of Octave |
Date: |
Mon, 4 Dec 2006 22:40:24 +0100 |
User-agent: |
KMail/1.9.5 |
Am Montag, 4. Dezember 2006 17:03 schrieb John W. Eaton:
> On 4-Dec-2006, David Bateman wrote:
> | Yes but you had to explicitly pass the "-I/usr/include/octave-2.1.73".
> | To my mind, the reason for the symbolic link would be that then you
> | wouldn't need the "-I" arguments to mkoctfile at all...
>
> Yes, if you are going to have the link then I think it should be
>
> /usr/include/octave -> /usr/include/octave-VERSION/octave
>
> I don't think we should change mkoctfile though. I think it will be
> more reliable if it uses -I options to pick up the specific version of
> the header files that correspond to the version of mkoctfile that is
> used.
That's fine with me.
> Or, until we have a stable API that can be expected to work across
> versions of Octave, you could just eliminate the symbolic link and
> assume that people will use mkoctfile to work with the Octave
> libraries.
The basic idea behind this link is actually Debian's alternatives system. In
theory, one could issue
update-alternatives --set octave octave2.9
and the respective links are all changed (mkoctfile => mkoctfile2.9, the above
link points to octave-2.9.9's include directory). We have however faced some
problems with that, due to our split of the packages, which means it doesn't
work right now.
> If they don't use mkoctfile, then it might not hurt to
> force them to be aware of the version that they are using, and that
> there is no stable API. If they complain about that, then ask them to
> assist in designing the stable API and doing the work necessary to
> maintain it...
You don't really expect this to work, do you ;)
Thanks
Thomas