* Bas Wijnen <wij...@debian.org> [2013-11-04 18:47:52 +0100]: > Hi, > > On Sun, Nov 03, 2013 at 11:19:44PM +0100, Nicolas Dandrimont wrote: > > Does this have anything to do with Slic3r packaging? > > No, this is a prerequisite for the Cura engine. I thought Slic3r used a > different library, but appearantly I was wrong? In that case I will need to > have a look at the perl package, because I suppose they have the same source > (I was planning to ignore the perl part and only package the c++ source from > upstream; it contains implementations in many other languages as well). > > I can't see it in the repository though; is it already in there?
There is no Perl library per se. Slic3r uses the C++ libpolyclipping via an XS++ wrapper (i.e. via a C++ Perl module). > > While debugging an issue with Slic3r on 32-bit archs, I tried upgrading to > > clipper 6.0.0 and Slic3r's test suite was broken. > > I have a 6.0.0 package just about ready to upload now; it might still take a > while before I do, though, because I added a pkgconfig file and upstream said > he wanted to include it, so I'll probably let that happen first. > > > However, upstream intends to move to clipper 6.0.0 just after its next > > release, so we might want to wait it out a bit. > > Good idea, I think. When we need it, we can just add a perl binary package > from my source package (some help with packaging would be welcome; I don't > know any perl). Slic3r should be able to dynamically link to the C library, so your package should be fine. I'll worry about the de-embedding side when libpolyclipping is available. Thanks, -- Nicolas Dandrimont BOFH excuse #443: Zombie processes detected, machine is haunted.
signature.asc
Description: Digital signature
