pyobjc-dev

[Pyobjc-dev] 2.2.x / non-framework build update

[Bill B. <bb...@co...>]

I just did a bit of an experiment and was successfully able to run the 
TableModel example against Python 2.2.1 using the standard system 
supplied version of Python.

I had to build the application wrapper by hand as the 
objc/buildtools.py script depends on functionality that is only a part 
of the Framework build of python.   Digging deeply into said 
functionality, most of it is centric to supporting resource forks and 
legacy mac issues which are not relevant to Cocoa development.

Everything else worked as expected.

I am going to invest some time into putting together a template 
Py-Cocoa project that uses a standard distutils style build formula to 
build a working, standalone, Cocoa application without requiring 
anything but the pyobjc module and the standard Python 2.2 that ships 
with OS X.

Everything is there... just a matter of putting the right bits in the 
right place.

There are three primary challenges:

	- generating an appropriately configured plist.  This is trivial, 
really.

	- putting something together that can be easily managed through 
project builder.   I can't think of anything hard here.
	
	- building a tiny bootstrap binary that can be stuck in the .app 
wrapper and be used to bootstrap the python interpreter with the 
appropriate script & arguments within the app wrapper.  This is 
actually pretty trivial, as well.

So -- nothing left to do but toss some code at the problem. :-)

b.bum

Re: [Pyobjc-dev] 2.2.x / non-framework build update

[Ronald O. <ous...@ci...>]

On Tuesday, Sep 24, 2002, at 16:30 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> I just did a bit of an experiment and was successfully able to run the 
> TableModel example against Python 2.2.1 using the standard system 
> supplied version of Python.
>
That's great. Did you have to change much in the pyobjc code?
>
> I am going to invest some time into putting together a template 
> Py-Cocoa project that uses a standard distutils style build formula to 
> build a working, standalone, Cocoa application without requiring 
> anything but the pyobjc module and the standard Python 2.2 that ships 
> with OS X.

If you find time to implement this I'm all for replacing the build 
script I wrote, as you said I'm depending on some legacy code that 
should not be necessary.

>
> There are three primary challenges:
>
> 	- generating an appropriately configured plist.  This is trivial, 
> really.
Not entirely trivial but close enough... I'd either like to see 
integration with PB or a standalone tool for editing the plist file. 
Plist files for document based applications are pretty simple, but I 
don't like to edit the XML by hand.

>
> 	- putting something together that can be easily managed through 
> project builder.   I can't think of anything hard here.
;-) that was what I thought when I started on my PyObjC updates ...
> 	
> 	- building a tiny bootstrap binary that can be stuck in the .app 
> wrapper and be used to bootstrap the python interpreter with the 
> appropriate script & arguments within the app wrapper.  This is 
> actually pretty trivial, as well.
Wouldn't the python binary in MacPython (aka the framework install) be 
usefull here? Please try to build something that allows access to the 
Carbon API's

Ronald

Re: [Pyobjc-dev] 2.2.x / non-framework build update

[Bill B. <bb...@co...>]

On Tuesday, September 24, 2002, at 12:23 PM, Ronald Oussoren wrote:
> On Tuesday, Sep 24, 2002, at 16:30 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> I just did a bit of an experiment and was successfully able to run 
>> the TableModel example against Python 2.2.1 using the standard system 
>> supplied version of Python.
>>
> That's great. Did you have to change much in the pyobjc code?

No changes required -- it was just a matter of hacking together the 
.app wrapper in the appropriate structure.

BTW:  I committed the changes to setup.py to allow pyobjc to build with 
Python 2.2.x against a non-framework build.  From here, it should be 
trivial to cut a release that can be built from a fink package -- it's 
on the todo list. :-)   If anyone wants to update the sourceforge pages 
and figure out how to cut a release, it would be most welcome.

PBX integration: I think the problem is a lot easier to solve than I 
initially thought, but I also know how dangerous that particular line 
of thinking is... I'll beat on it on the train this evening.

Also, I think we should move the subclass-branch to the trunk.   It is 
so far beyond the trunk at this point that I can't imagine development 
continuing on the trunk.

b.bum