From: Bill Bumgarner <bbum@co...> - 2003-01-23 07:14:05
On Thursday, Jan 23, 2003, at 01:52 US/Eastern, David Eppstein wrote:
> On 1/23/03 1:48 AM -0500 Bill Bumgarner <bbum@...> wrote:
>> If you are going to build with FFI support-- it will eventually become
>> the only way to build pyobjc-- you will currently need to download the
>> libffi snapshot that Ronald put together.
>> ... for the download link. The tarball contains a 'README.ronald'
>> with instructions. I installed libffi with a prefix of /usr/local/
>> it works fine.
> What (if anything) does this imply about the ability to produce
> standalone apps that do not require installs of random libs in random
> parts of the filesystem?
Good question -- I should have clarified that in the original message.
Nothing, at least nothing permanent.
One of the primary goals-- requirements really-- of PyObjC is that it
continues to work with the stock Apple Python from standalone,
double-clickable, "normal" applications.
Lib FFI is linked statically -- once PyObjC is built, the module can be
copied into the app wrapper and shipped w/a standalone app just like
you normally would.
The current state of affairs is suboptimal -- at some point, we will
figure out how to stick libffi into the pyobjc source or build such
that there isn't a prerequisite for building. For the moment, it is a
bit wonky -- while LibFFI support works very well [all unit tests that
should pass do pass], the build environment needs to be cleaned a bit.
(Ronald: Maybe we should stick libFFI.a and the two/three headers into
pyobjc's CVS directly?)
On Thu, 23 Jan 2003 02:13:46 -0500, Bill Bumgarner wrote
> (Ronald: Maybe we should stick libFFI.a and the two/three headers
> into pyobjc's CVS directly?)
Only if it is for a short period. I like adding the libFFI sources better.
Even then these files should be clearly marked as being an external project
and we should avoid making changes to those sources.