Re: octave-gsl 2.1.1 released

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

Re: octave-gsl 2.1.1 released

jbect
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.

Disclaimer : I have very limited experience with autoconf, so this might
not be the best way to do it.  Advice from experimented autoconf-ers
most welcome.

-----

On a different topic : I always found it weird to have a package simply
named "gsl", since gsl (or GSL) is also the name of the underlying library.

This introduces confusion between the library release number and the
package release number.  For instance, I have just compiled gsl 2.1.1
using gsl 2.5...

We also sometimes end up having a tarball for the octave package with
the same name as the one for the library...

I suggest to rename the octave package from "gsl" to "octave-gsl" to
avoid this confusion...  (This is already the name of the corresponding
Debian package, for instance.)

@++
Julien


Reply | Threaded
Open this post in threaded view
|

Deprecation warnings in Octave Forge packages

Oliver Heimlich
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

https://sourceforge.net/p/octave/interval/ci/default/tree/src/compatibility/

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.

Oliver


signature.asc (499 bytes) Download Attachment