<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 4, 2014 at 7:46 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Apr 4, 2014, at 18:05, Brandon Allbery wrote:<div class="">
> If they're pure perl then that might work; if there's any XS involved then a hard version dependency would be needed.<br>
<br>
</div>How would we determine that?<br>
I don’t know enough about perl to know what “XS” means.<br>
</blockquote></div><br>XS is Perl's extension mechanism. If there is non-perl code (C, C++, etc.) involved with a module, there must be XS glue to hook it into perl; this code will not be binary compatible with anything but the perl it was built against, and may be source incompatible with different perl versions (I've helped a few people in IRC who found that modules we'd been building successfully against perl 5.12 got XS build errors against 5.16).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This may include upcalls back into a program such as irssi that supports Perl extensions, since the upcalls will probably require XS glue unless the interface was designed to use e.g. a socket to do remote procedure calls.<br clear="all">
<div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div>