http://qs321.pair.com?node_id=1185014

vrk has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

at $work, we use SWIG to generate a Perl wrapper for a large C++ library. SWIG creates glue code in XS and pure Perl based on the C++ class definitions, and the XS code is then compiled against the header files of a particular version of Perl. This works great and you can use the same SWIG interface file to generate a Python, Java and C# wrapper as well.

The problem is, when the XS code is compiled against a particular version of Perl, say 5.18, the resulting compiled library is only compatible with the same (major) version of Perl. Our customers use a range of Perl versions, from 5.10 through to the latest one, so we have to compile and provide support for an ever increasing number of versions, even though the actual C++ library is exactly the same in each case. It was manageable for 5.6 and 5.8, which were long-lived versions, but it's become exasperating since the move to annual Perl releases.

Can you point me to any resources that describe or discuss the rationale for why XS code could not be made binary compatible between Perl versions? Or why there couldn't be some kind of reduced XS API that would stay binary compatible even if some parts change? Which authority should I petition to make it so?