On 10/10/2011 05:42 AM, Tony Cook wrote: > On Sun, Oct 09, 2011 at 08:58:12PM +0200, Steffen Mueller wrote: >> Hey, >> >> Sorry for the delay. >> >> On 09/09/2011 10:57 AM, Tony Cook wrote: >>> On Fri, Sep 09, 2011 at 08:12:50AM +0200, Steffen Mueller wrote: >>>> Any ideas? Takers? I'd just love to have a backward compatible way >>>> to fix typemaps. >>> >>> Simple and dumb: >>> >>> Provide a T_AVREF_FIXED, XS modules that want the fixed behaviour can >>> add a C<AV * T_AVREF_FIXED> entry to their local typemap. >> >> Indeed. And this is pretty much what I just did (including tests in >> XS::Typemap). > > Makes sense to me. > > The other option was an attempt to make it less manual, but that > really isn't possible. The other option would reduce the number of manual steps to be taken in future when there's many of these quirks to work around. If all you need to get ALL fixes is declaring that you want a typemap version > X, then that's a win. What I wasn't entirely comfortable with was understanding and making educated decisions about versioning the core typemap vs. versioning the evolving typemap format vs. making typemaps "named" and versioning any given named typemap like you would a module. This is partly why I originally suggested using modules for this. We have a somewhat reasonable* module/versioning/dependency toolchain and ExtUtils::Typemaps allows abusing that for typemaps. I used this, for example, to auto-import typemaps from modules in Module::Build::WithXSpp. It's not elegant, but it demonstrates a possible way to get this working. Cheers, Steffen * Only somewhat reasonable because if you're not up for using the latest version of everything, you're kind of fucked with our current setup.Thread Previous