Bug 1032181 - Templated types are causing "Could not find a typemap for C type"
Summary: Templated types are causing "Could not find a typemap for C type"
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-ExtUtils-ParseXS
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1032056
TreeView+ depends on / blocked
Reported: 2013-11-19 16:48 UTC by Miro Hrončok
Modified: 2014-03-20 07:21 UTC (History)
2 users (show)

Fixed In Version: perl-ExtUtils-ParseXS-3.18-292.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1078438 (view as bug list)
Last Closed: 2014-03-20 07:09:19 UTC
Type: Bug

Attachments (Terms of Use)
Patch that solves the issue (7.38 KB, patch)
2013-11-19 16:48 UTC, Miro Hrončok
no flags Details | Diff
Minimal fix (3.26 KB, patch)
2013-11-20 12:06 UTC, Petr Pisar
no flags Details | Diff

Description Miro Hrončok 2013-11-19 16:48:04 UTC
Created attachment 826208 [details]
Patch that solves the issue

Description of problem:
When using perl-ExtUtils-ParseXS to build XS stuff (I don't know the terminology here, sorry), errors like this happens:

Version-Release number of selected component (if applicable):

How reproducible:
Happend when building slic3r-xs

Steps to Reproduce:
1. Get slic3r tarball from https://github.com/alexrj/Slic3r/archive/1.0.0RC1.tar.gz
2. unpack && cd Slic3r-1.0.0RC1/xs/ # be usre to be in xs folder
3. perl Build.PL && ./Build

Actual results:
Could not find a typemap for C type 'std::vector< double >'.
The following C types are mapped by the current typemap:
'AV *', <snip>, 'wchar_t *'
 in /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/typemap.xspt"  "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/TriangleMesh.xsp", line 138

Expected results:
No errors, just warnings

Additional info:
This is fixed in upstream release 3.22 and also in development release 3.18_03.

I backported the fix, patch is attached.

Comment 1 Petr Pisar 2013-11-20 11:38:51 UTC
The patch moves tidy_type() from ExtUtils::ParseXS::Utilities to ExtUtils::Typemaps. The patch improves tidy_type(). The patch removes _tidy_type() from ExtUtils::Typemaps.

ExtUtils::ParseXS::Utilities is declared as not a public API explicitly.

The patch is based on perl commit:

commit ae7fdf584559a304eb5992a58cd58349cc7c58da
Author: Steffen Mueller <smueller@cpan.org>
Date:   Wed May 22 21:49:06 2013 +0200

    EU::ParseXS: Attempt to canonicalize C++ types in tidy_type
    Includes moving tidy_type to ExtUtils::Typemaps where it seems to
    belong. It's a pretty poor canonicalizer, but better than nothing!

The key change is:

+  # for templated C++ types, do some bit of flawed canonicalization
+  # wrt. templates at least
+  if (/[<>]/) {
+    s/\s*([<>])\s*/$1/g;
+    s/>>/> >/g;
+  }

in tidy_type().

Comment 2 Petr Pisar 2013-11-20 12:06:36 UTC
Created attachment 826591 [details]
Minimal fix

This ports only the fix without breaking API.

Comment 3 Fedora Update System 2013-11-20 12:22:00 UTC
perl-ExtUtils-ParseXS-3.18-292.fc20 has been submitted as an update for Fedora 20.

Comment 4 Miro Hrončok 2013-11-20 13:17:14 UTC
Thanks a lot for the minimal fix.

Comment 5 Fedora Update System 2013-12-14 03:32:38 UTC
perl-ExtUtils-ParseXS-3.18-292.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Petr Pisar 2014-03-20 07:09:19 UTC
I guess only F20 was concerned.

Note You need to log in before you can comment on or make changes to this bug.