One typemap to rule them all

[Dave Mitchell]

I recently realised that the "system" typemap file bundled with perl is
unrelated to the ExtUtils::ParseXS distro.

So there's a git-managed file in core,

lib/ExtUtils/typemap

which gets installed as lib/5.x.y/ExtUtils/typemap, and which is used by
default by all XS distros when being installed within that perl
installation.

Separately, there is a file,

dist/ExtUtils-ParseXS/t/typemap

which is used by the tests when building and testing ExtUtils-ParseXS.

The ParseXS typrmap file looks to have been copied at some time around
5.12.0 from the system one , but has since bit-rotted. I have a PR which
(amongst many other things) resyncs them, but I feel that the long-term
solution should involve unifying the two files in some way.

My gut feeling is that *ParseXS* should hold the 'master' copy of typemap,
which is copied then to lib/ExtUtils/typemap while perl is being built:
possibly in particular, "cd dist/ExtUtils-ParseXS; make" should do
the equivalent of 'cp typemap ../../lib/ExtUtils/typemap' or similar. In
theory nothing should need lib/ExtUtils/typemap to be present before
ExtUtils-ParseXS has been installed.

If so, then first there's the question of where the typemap file should
reside within dist/ExtUtils-ParseXS/. The current location, t/typemap
implies that it's a custom file just for test purposes. I think perhaps it
should become either

dist/ExtUtils-ParseXS/typemap
dist/ExtUtils-ParseXS/lib/ExtUtils/typemap

There's then the issue of what happens when someone installs a newer
ParseXS from CPAN onto an older perl. Currently the older perl gets the
newer ParseXS, but still uses the older system typemap. Presumably
the older perl should instead get the new typemap, perhaps installed
as

lib/site_perl/5.x.y/ExtUtils/typemap

which is then loaded in preference to the "system" one,

lib/5.x.y/ExtUtils/typemap

Does any of that make any sense? And so, does anyone know how easy it
would be to implement? Can the toolchain automate most/all of this? E.g.
will having the file dist/ExtUtils-ParseXS/lib/ExtUtils/typemap being
present cause it to automatically be installed under lib/ExtUtils in a git
blead build, and under lib/site_perl/5.x.y/ExtUtils/ in a CPAN install?
Or does this have to be hand-cranked in some fashion?

[Tony Cook]

Post by Dave Mitchell
There's then the issue of what happens when someone installs a newer
ParseXS from CPAN onto an older perl. Currently the older perl gets the
newer ParseXS, but still uses the older system typemap. Presumably
the older perl should instead get the new typemap, perhaps installed
as
lib/site_perl/5.x.y/ExtUtils/typemap
which is then loaded in preference to the "system" one,
lib/5.x.y/ExtUtils/typemap
Does any of that make any sense? And so, does anyone know how easy it
would be to implement? Can the toolchain automate most/all of this? E.g.
will having the file dist/ExtUtils-ParseXS/lib/ExtUtils/typemap being
present cause it to automatically be installed under lib/ExtUtils in a git
blead build, and under lib/site_perl/5.x.y/ExtUtils/ in a CPAN install?
Or does this have to be hand-cranked in some fashion?

One problem with this is the core typemap uses functions that are only
defined in newer perls such as sv_setrv_noinc().

I could see the failure cases for T_IN, T_INOUT etc changed to use
sv_set_undef() too.

Tony

[Paul "LeoNerd" Evans]

On Thu, 16 Jan 2025 16:23:38 +1100

Post by Tony Cook
One problem with this is the core typemap uses functions that are only
defined in newer perls such as sv_setrv_noinc().

Is that something the usual `#if HAVE_PERL_VERSION...`-style of
version-guarding macros could help with?