In article <d7k9b4$nqi$1 / license1.unx.sas.com>, Tim Hunter wrote:

> Jeremy Henty wrote:
>> OK, so if I add 'have_func("rb_block_proc")' to extconf.rb and:
>> 
>> #ifndef HAVE_RB_BLOCK_PROC
>> #define rb_block_proc rb_f_lambda
>> #endif
>> 
>> to the header file, I can globally replace rb_f_lambda by
>> rb_block_proc everywhere else and the result will build under 1.6.x ?
> 
> ... I suggest you pick a 3rd, all-caps, symbol to use as the
> preprocessor symbol: ... Since it's very common to make preprocessor
> symbols all-caps (and very uncommon for function names to be
> all-caps) when the next maintainer starts looking at your source
> code, the BLOCK_PROC symbol will prompt him/her to go look for its
> definition in a header file.

I'm aware of that convention and I would *certainly* do that if I was
using macros to create a consistent API around inconsistent
lower-level APIs (in the same way that Glib/Gtk create a consistent
API on top of the Unix, Windows and Mac APIs).  In these cases there
isn't any way to write portable code without creating such wrappers so
it's good to highlight their existence.

But this situation is different.  Here I just want a workaround to
make pukka Ruby-1.8.x code build and run correctly on Ruby-1.6.x too.
It's a backward step to force a Ruby-1.8.x developer to use a new API
to write portable code when I can arrange for the build to silently do
the Right Thing on Ruby-1.6.x *even* if the developer knows nothing of
the portability issues.  So in this case I prefer my approach.  But
I'm willing to be persuded otherwise.

Cheers, 

Jeremy Henty