On Wed, 2007-08-01 at 14:53 +0200, Thierry Vignaud wrote: > build failled: > > /usr/bin/perl5.8.8 /usr/lib/perl5/5.8.8/ExtUtils/xsubpp -noprototypes > -typemap /usr/lib/perl5/5.8.8/ExtUtils/typemap > -typemap /home/tv/rpm/BUILD/Gtk2-1.154/build/gtk2perl.typemap > -typemap /home/tv/rpm/BUILD/Gtk2-1.154/gdk.typemap > -typemap /home/tv/rpm/BUILD/Gtk2-1.154/gtk.typemap > -typemap /home/tv/rpm/BUILD/Gtk2-1.154/pango.typemap > -typemap /usr/lib/perl5/vendor_perl/5.8.8/i386-linux/Glib/Install/typemap > -typemap > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux/Cairo/Install/cairo-perl-auto.typemap > -typemap > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux/Cairo/Install/cairo-perl.typemap > xs/PangoCairo.xs > xs/PangoCairo.xsc && mv xs/PangoCairo.xsc xs/PangoCairo.c > Error: 'PangoCairoFont *' not in typemap in PangoCairo.xs, line 101
Hmm. I think this happens because you compile against pango < 1.17.x. In this case the type mapping for PangoCairoFont is not created. This wouldn't be a problem, since the concerned method is only compiled when pango >= 1.17.x, if the XS preprocessor respected the C preprocessor version guards. But it doesn't and so it demands the presence of a typemap for PangoCairoFont anyway. I only see two possible solutions: a) Make the typemap available regardless of pango's version. That's problematic since the presence of a typemap would imply usable wrappers for this type even though the underlying C structures and types aren't there at all. b) Put the one xsub using PangoCairoFont into its own file and include that file in the compilation only if pango >= 1.17.x. This is actually how we normally deal with this kind of situation. But in this particular case it would suck anyway, because a separate file for one xsub is rather wasteful and cumbersome. Did I miss any alternative? -- Bye, -Torsten _______________________________________________ gtk-perl-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
