<br><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 1:58 PM, Bernhard Herzog <span dir="ltr"><<a href="mailto:bh@intevation.de" target="_blank">bh@intevation.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<a href="mailto:scm-commit@wald.intevation.org" target="_blank">scm-commit@wald.intevation.org</a> writes:<br>
<br>
> Author: igor_n<br>
> Date: 2010-09-23 14:02:00 +0200 (Thu, 23 Sep 2010)<br>
> New Revision: 736<br>
><br>
> Added:<br>
> skencil/branches/skencil-0.6/src/extensions/Modules/ImPlatform.h<br>
> skencil/branches/skencil-0.6/src/extensions/Modules/Imaging.h<br>
> Modified:<br>
> skencil/branches/skencil-0.6/src/extensions/Modules/skimage.c<br>
> Log:<br>
> fix to simplify PIL support<br>
<br>
Is that really a good idea? Are we sure that there are now binary<br>
incompatible changes between different PIL versions? From which PIL<br>
version are these, anyway?<br>
<br>
Bernhard<br>
_______________________________________________<br>
Skencil-devel mailing list<br>
<a href="mailto:Skencil-devel@wald.intevation.org" target="_blank">Skencil-devel@wald.intevation.org</a><br>
<a href="http://lists.wald.intevation.org/mailman/listinfo/skencil-devel" target="_blank">http://lists.wald.intevation.org/mailman/listinfo/skencil-devel</a><br>
</blockquote></div><br>As you know PIL support is a troubles source for packages with native <br>binding to PIL image object because PIL headers are installed in different places <br>depending on distro. Sometimes not in /usr/include but in /usr/lib/$PYTHON/...<br>
In Skencil mail list you can find related threads.<br>
<br>Skencil native extension includes core ImagingMemoryInstance structure <br>reference only. The structure is not changed during latest versions including <br>last 1.1.8 version. So including these headers simplifies a project build<br>
under different platforms. If this structure will be changed in future PIL<br>versions we will need fixing skimage.c code anyway. Because even now<br>access to ImagingMemoryInstance is rather a hack than a regular <br>solution due to PIL architecture
(in skimage.c there is redefining for <br>ImagingObject structure)<br><br>As alternate way we can redefine ImagingMemoryInstance in skimage.c<br><br>-- <br>Regards,<br><br>Igor Novikov<br>sK1 Project<br><a href="http://sk1project.org" target="_blank">http://sk1project.org</a><br>
<br><br>