Bug 1032181

Summary: Templated types are causing "Could not find a typemap for C type"
Product: [Fedora] Fedora Reporter: Miro Hrončok <mhroncok>
Component: perl-ExtUtils-ParseXSAssignee: Petr Pisar <ppisar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: perl-devel, ppisar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: perl-ExtUtils-ParseXS-3.18-292.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1078438 (view as bug list) Environment:
Last Closed: 2014-03-20 07:09:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1032056    
Attachments:
Description Flags
Patch that solves the issue
none
Minimal fix none

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:
https://rt.cpan.org/Public/Bug/Display.html?id=86367

Version-Release number of selected component (if applicable):
perl-ExtUtils-ParseXS-3.18-291.fc20.noarch

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:
<snip>
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>
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.
https://admin.fedoraproject.org/updates/perl-ExtUtils-ParseXS-3.18-292.fc20
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.