C API version / functionality detection

What is a reliable and future proof way of detecting available functions
in the Ruby C
API? In particular I would like to use rb_obj_is_proc, rb_proc_arity
etc,
which both seem to be only in 1.9 and later. I've read that there is no
version macro to use,
so one has to use some other macro to determine what is available. What
should
one be using? The best I can see is to use something like T_COMPLEX
which was
introduced in 1.9, however, this has nothing to do with the Proc
enhancements:

#if defined(T_COMPLEX) // T_COMPLEX introduced in 1.9
  if ( rb_obj_is_proc( obj ) == Qtrue ) // Only available in 1.9
#else
  if ( rb_respond_to( obj, rb_intern("call") ) == Qtrue ) // Does not
work in 1.9 and later
#endif

Clearly I need to seemlessly support different versions from C.

···

--
Posted via http://www.ruby-forum.com/.

The RUBY_VERSION macro?

http://rxr.whitequark.org/mri/source/version.h#001

···

--
Matma Rex

Macros containing text such as RUBY_VERSION can't be usefully used by
the C preprocessor, but the numeric ones such as RUBY_API_VERSION_CODE
or the old RUBY_VERSION_CODE can be. However, they are in version.h
which poses two problems. First this file isn't always shipped (eg in
some Debian based system, such as ruby-1.9.0 on Ubuntu 10.04). Secondly
in order to get the macro one needs a '#include "version.h"' which is a
rather commonly named file name, so it may pick up some other version.h
file which is no good at all as our users are expected to use their own
code.

Anyway, I've fixed the problem above as rb_respond_to changed in a
subtle way in 1.9 and the '== Qtrue' should be dropped to check for
success.

Even so, it is still nearly impossible to write extensions using new
APIs if one cannot reliably determine if a new API is available or
detect the version that they might have changed in.

···

--
Posted via http://www.ruby-forum.com/.

Macros containing text such as RUBY_VERSION can't be usefully used by
the C preprocessor, but the numeric ones such as RUBY_API_VERSION_CODE
or the old RUBY_VERSION_CODE can be. However, they are in version.h
which poses two problems. First this file isn't always shipped (eg in
some Debian based system, such as ruby-1.9.0 on Ubuntu 10.04). Secondly
in order to get the macro one needs a '#include "version.h"' which is a
rather commonly named file name, so it may pick up some other version.h
file which is no good at all as our users are expected to use their own
code.

Instead of version.h, I suggest ruby/version.h
#include <ruby/version.h>

Anyway, I've fixed the problem above as rb_respond_to changed in a
subtle way in 1.9 and the '== Qtrue' should be dropped to check for
success.

Using RTEST() should work reliably.

···

William Fulton <lists@ruby-forum.com> wrote: