On 9 January 2014 08:04, William S Fulton <address@hidden> wrote:
William S Fulton wrote
Commit http://hg.savannah.gnu.org/hgweb/octave/rev/b6b6e0dc700e looks like
it will satisfy our needs. Thanks for restoring some sort of usable
versioning.
It isn't quite as I'd hoped for detecting 3.8.0. Seems that version 3.2 and
earlier doesn't define OCTAVE_API_VERSION_NUMBER in version.h either, so
John Eaton's suggestion for detecting 3.8.0 doesn't work because neither
OCTAVE_API_VERSION_NUMBER nor OCTAVE_{MAJOR,MINOR,PATCH} are defined in
3.8.0 or versions <=3.2. We already have quite a bit of preprocessor logic
for versions < 3.2. Can you please suggest a header that is available in all
versions of Octave <= 3.2 and in 3.8.0 which contains a macro to distinguish
3.8.0 from earlier versions? Perhaps using the talked about features can be
used as a hack to detect 3.8.0?
I'm confused. The whole problem here is that OCTAVE_API_VERSION_NUMBER
was dropped in 3.8.0. Now the problem is that the previously working
version of Octave, 3.2.0, also did not have it defined? Whatever logic
you're using to identify 3.2.0, does not work anymore?
Also, Octave 3.2.0 is quite old and the usual stance when users have
problems with it is to upgrade. Your ubuntu may only be 20 moths old,
but that version was released 4 years ago and 3.4 was released 3 years
ago. I believe the reason it still has Octave 3.2 is because the
Debian testing it was based on, was frozen for a very long time. We
redirect Ubuntu users to our PPA.