swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swftools-common] [PATCH] Refactored environment variable overrides


From: Kai Lautaportti
Subject: Re: [Swftools-common] [PATCH] Refactored environment variable overrides for setup.py
Date: Fri, 2 Oct 2009 09:24:10 +0300

On Thu, Oct 1, 2009 at 5:48 PM, Matthias Kramm <address@hidden> wrote:
> On Wed, Sep 30, 2009 at 10:22 PM, Kai Lautaportti
> <address@hidden> wrote:
>> We only use gfx ourselves and linking SWF against PIL (_imaging.so)
>> has turned out problematic on OSX. By default the PIL .so libraries
>> are created as bundles on OSX which cannot be linked against.
>
> Is there some way to detect in setup.py whether linking against _imaging.so
> would work?

Perhaps, but I'm not sure of a best way to do that in a portable manner.

> It's possible to build the SWF module without _imaging support.

Ok, looking at the code I see the all PIL functionality is wrapped
inside #ifdef HAVE_PYTHON_IMAGING.

The current setup.py however doesn't support opting out of PIL. Would
you be more comfortable with implementing a choice of using PIL in
setup.py instead of (optionally) leaving out SWF alltogether as it is
in my proposed patch?

I don't feel strongly either way as long as the ``gfx`` module builds
cross-platform.

>
>> I was able to manually hack PIL so that the libs are built using
>> -dynamiclib instead of -bundle which allowed the linking but in our
>> case it is far easier to just disable SWF alltogether. Also, I recall
>> hearing that you were thinking about deprecating the SWF module.. is
>> that correct?
>
> Well, I don't maintain it anymore, and nobody is using it, so yes, that is
> presumably the direction where that module is headed.

If this is the case then perhaps just ditching the module would be an
option? If it doesn't have an active maintainer it will bitrot in any
case.

cheers,
Kai

-- 
CTO Kai Lautaportti
Hexagon IT Oy

address@hidden
www.hexagonit.fi
+358-40-486-9803




reply via email to

[Prev in Thread] Current Thread [Next in Thread]