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.
Get latest updates about Open Source Projects, Conferences and News.