Passing this along. I don't know how prevalent SWIG support for Octave
is used (I only know of plplot), so maybe this isn't that big of a deal.
But it would be really nice if the Octave and SWIG folks could work
this out. I may be done being a go between at this point though.
-------- Original Message --------
Subject: [swig:bugs] #1353 Octave 3.8.0 support
Date: Sun, 05 Jan 2014 13:45:11 +0000
From: William Fulton <wsfulton@...>
Reply-To: [swig:bugs] <1353@...>
To: [swig:bugs] <1353@...>
There is no configure stage for SWIG to utilise when generating code. If
there are C macros in the Octave headers (as a result of an Octave
configure) that turn features on and off and they are officially
documented, then we can use those. However to deal with changing apis,
NOT features, an API version is needed. APIs always change even if not
intentional, someone will someday mess up and we will need an API
version number to fix these kind of errors.
The string version OCTAVE_API_VERSION is absolutely useless for use by
the C preprocessor.
If users of Octave, such as SWIG find the API version number useful, I
strongly urge for it to be re-instated. Otherwise I propose dropping
support for Octave in SWIG 3.0 as it will taint the SWIG reputation for
not working and provide too much of a support burden on SWIG maintainers
such as myself. I've started a discussion on the swig-devel mailing
list. Please join in. Can someone familiar with Octave please set up a
discussion with the Octave maintainers and us SWIG maintainers.
Sent from sourceforge.net because you indicated interest in
Get latest updates about Open Source Projects, Conferences and News.