libclass-xsaccessor-perl: defining PERL_CORE for external XS modules and ABI stability

[Ansgar Burchardt <ansgar@43-1.org>]

Hi,

the last upstream release of libclass-xsaccessor-perl (1.07) contains
this change:

--8<---------------cut here---------------start------------->8---
--- XSAccessor.xs       (revision 61639)
+++ XSAccessor.xs       (working copy)
@@ -1,7 +1,33 @@
 #define PERL_NO_GET_CONTEXT
 #include "EXTERN.h"
 #include "perl.h"
+
+/*
+ * Quoting chocolateboy from his Method::Lexical module at 2009-02-08:
+ *
+ * for binary compatibility (see perlapi.h), XS modules perform a function call to
+ * access each and every interpreter variable. So, for instance, an innocuous-looking
+ * reference to PL_op becomes:
+ *
+ *     (*Perl_Iop_ptr(my_perl))
+ *
+ * This (obviously) impacts performance. Internally, PL_op is accessed as:
+ *
+ *     my_perl->Iop
+ *
+ * (in threaded/multiplicity builds (see intrpvar.h)), which is significantly faster.
+ *
+ * defining PERL_CORE gets us the fast version, at the expense of a future maintenance release
+ * possibly breaking things: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-04/msg00171.html
+ *
+ * Rather than globally defining PERL_CORE, which pokes its fingers into various headers, exposing
+ * internals we'd rather not see, just define it for XSUB.h, which includes
+ * perlapi.h, which imposes the speed limit.
+ */
+
+#define PERL_CORE
 #include "XSUB.h"
+#undef PERL_CORE
 
 #include "ppport.h"
 
--8<---------------cut here---------------end--------------->8---

I wonder whether it is safe to keep this in Debian as the XS modules depend
on perlapi-*, or if this does not guarantee that (internal) offsets do
not change and we should not define PERL_CORE for the Debian package.

Regards,
Ansgar