macro for building packages with different Octave versions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

macro for building packages with different Octave versions

Olaf Till-2
Hi,

symbols in Octave sometimes change, requiring some consideration if
packages with C++ code should be compatible with several major Octave
versions.

Some time ago Carnë offered some tests for single deprecated symbols
in Octave.

My strategy has been not to test, but to use the deprecated symbols as
long as possible and then to switch to the new symbols. But this
strategy doesn't seem to work, since not all deprecated symbols are
available for more than one major Octave version.

Trying to simplify checking for and building with simple cases of
alternative Octave symbols, I made an autoconf macro which does the
more tedious part of the job. It probably should be made available at
the Octave Forge website. My programming of autoconf macros is not
very good, so I'd appreciate comments and improvements. The macro and
an example call are at:

https://savannah.gnu.org/patch/index.php?9410

The macro file contains a further explanation in the comment block
above the second macro.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: macro for building packages with different Octave versions

jbect
Le 17/07/2017 à 16:37, Olaf Till a écrit :

> symbols in Octave sometimes change, requiring some consideration if
> packages with C++ code should be compatible with several major Octave
> versions.
>
> Some time ago Carnë offered some tests for single deprecated symbols
> in Octave.
>
> My strategy has been not to test, but to use the deprecated symbols as
> long as possible and then to switch to the new symbols. But this
> strategy doesn't seem to work, since not all deprecated symbols are
> available for more than one major Octave version.
>
> Trying to simplify checking for and building with simple cases of
> alternative Octave symbols, I made an autoconf macro which does the
> more tedious part of the job. It probably should be made available at
> the Octave Forge website. My programming of autoconf macros is not
> very good, so I'd appreciate comments and improvements. The macro and
> an example call are at:
>
> https://savannah.gnu.org/patch/index.php?9410
>
> The macro file contains a further explanation in the comment block
> above the second macro.

Hi Olaf,

I fully support your initiative, because I think that supporting several
major versions of Octave for as many OF packages as possible is important.

For instance, Ubuntu 14.04 LTS (EOL April 2019) still has Octave 3.8.1
and Debian Jessie (EOL June 2018, LTS June 2020) has Octave 3.8.2.

I can't help you with the autoconf part, however, since my own
experience with autoconf is very limited (a few hacks on the octave-gsl
package, nothing more).

Concerning the diffusion of these macros, one idea would be to create a
simple OF package that contains both the macros themselves and a few
example oct-files with BISTs.  This would make it easier to test that
the macros are effectively working on a large range of Octave versions.

@++
Julien

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: macro for building packages with different Octave versions

Olaf Till-2
On Wed, Jul 19, 2017 at 09:09:04AM +0200, Julien Bect wrote:
> Concerning the diffusion of these macros, one idea would be to create a
> simple OF package that contains both the macros themselves and a few example
> oct-files with BISTs.

This reminds me of JPs suggestion of creating a template package. Up
to now I didn't see what information could be in it except what is
already covered by the Octave manual and by the hint at OF to use the
maintainer Makefile. But the current issue could indeed be a "use
case" for a template package, and maybe there are more(?).

BTW, since you mentioned Debian Jessie, Debian recently has made a new
stable release. But it has Octave-4.0, so your argument still applies.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: macro for building packages with different Octave versions

jbect
Le 19/07/2017 à 09:43, Olaf Till a écrit :
> On Wed, Jul 19, 2017 at 09:09:04AM +0200, Julien Bect wrote:
>> Concerning the diffusion of these macros, one idea would be to create a
>> simple OF package that contains both the macros themselves and a few example
>> oct-files with BISTs.
> This reminds me of JPs suggestion of creating a template package. Up
> to now I didn't see what information could be in it except what is
> already covered by the Octave manual and by the hint at OF to use the
> maintainer Makefile. But the current issue could indeed be a "use
> case" for a template package, and maybe there are more(?).

I was not thinking of it as a "template package" but, yes, now that you
mention it, it could very well serve that purpose too.

Among its possible uses, here are a few I can think of :

* it could be a natural location to store the template MM (instead of
the project-web repo ?) as you suggest,

* it could be a natural location to provide a minimal working example of
a package (with DESCRIPTION, INDEX, a small manual, etc.),

* it could provide examples of "portable oct-file writing" (using your
autoconf macros to support as many Octave versions as possible) with
BISTs as proposed in my previous email,

* perhaps could it also contain simple examples of how new types can be
added to Octave through oct-files,

* ...


> BTW, since you mentioned Debian Jessie, Debian recently has made a new
> stable release. But it has Octave-4.0, so your argument still applies.

I mentioned Jessie because it is far from having reached its end of
life, and thus should not be considered an obsolete release.


Loading...