[Top][All Lists]

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

Deprecation warnings in Octave Forge packages

From: Oliver Heimlich
Subject: Deprecation warnings in Octave Forge packages
Date: Sun, 24 Jun 2018 23:02:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 23.06.2018 14:47, Julien Bect wrote:
> Le 23/06/2018 à 14:25, Julien Bect a écrit :
>> Hi all,
>> A new release of the gsl package for Octave is out (version 2.1.1).
>> This is a minor release, which removes a bunch of deprecation warnings
>> introduced by Octave 4.4.
> Package managers having to deal with deprecation warnings such as
> octave_value::is_real_type -> octave_value::isreal might be interested
> in this particular file :
> https://sourceforge.net/p/octave/gsl/ci/tip/tree/src/configure.ac.in
> which shows how both recent and ancient versions of Octave can be
> supported using autoconf.

I have two further suggestions to handle deprecation warnings.

The first is the easiest, you could just ignore them.  The current code
is still going to work until the next major release of Octave.  Once
this has happened, you can change the code and then make a new package
release which is compatible with the then-stable version of Octave as
well as with version 4.4.  If you can live with dropping support for
Octave 4.2 once Octave 5 has been released, you don't have to handle
different API versions of particular functions at all.

The second suggestion is an alternate approach to reaching API
compatibility with different Octave versions in an Octave package.
Since I am not familiar with autotools as well, and I don't like the use
of macros in my code, I have implemented the needed API wrappers in C++
code, see


The idea is to define wrapper functions, implement them for the current
API in octave_current.cc, and implement them for older API versions in
octave_X.Y.cc, where X.Y is an old major release of Octave.  During
package installation, the implementation will be selected.

The package's C++ code can then be written for the current API version
(plus a few wrapper functions), without macros.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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