Re: [Pyobjc-dev] buildapplication strawman

[<bb...@ma...>]

(Cursory comments-- a lot of this is about stuff that I know little 
about [framework build, Carbon stuff, MacPython], so take it with a 
grain of salt)

On Tuesday, November 19, 2002, at 08:26 AM, Jack Jansen wrote:
>> - I would not let people specify a nib by path, but by name, 
>> defaulting to
>>   "MainMenu". The .lproj or individual nibs should then be listed as a
>>   resource.
>
> Why? If there is a good reason to disallow full pathnames: fine with 
> me, but I don't
> immediately see why this would be so.

If one uses the CFBundle/NSBundle APIs to obtain the path to the NIB 
file, then localization "just works".  Full pathnames defeat this 
feature of the OS.   Similarly, using the NSMainNIB key (whatever it is 
called) also exercises the localization features.

>> Further things I'd like to do:
>>
>> - Change it to use the os.execve() trick.
>
> Definitely, but as an option. The only thing I'm not sure about is 
> whether the execve code
> should be in-line in a string (as in your version) or external on 
> sys.path (as buildtools.py
> currently does).

If it is to work with the Apple distribution of Python, then the 
assumption must be that it won't necessarily be available in the python 
installation?  Even in a development environment, there is no need for 
the user to install pyobjc into the python distribution -- 
non-administrators can and should be able to use PyObjC and the related 
development tools without an administrative-only installation phase.

>> - I would like to add a debug or "developer" option: instead of 
>> copying the
>>   files/folders it would put symlinks inside the bundle. That way 
>> it's easy
>>   to keep on hacking on any file without having to rebuild the app 
>> all the time.
>
> Yes, good idea.

WebObjects has a feature called 'rapid turnaround mode'.  It works in a 
similar fashion, but doesn't use symlinks.  I have been looking into 
how to do the same with PyObjC based applications.  But, in reality, 
symlinks work just fine .

>> - Add modulefinder support, like we discussed by telepathy... The 
>> full version
>>   would also copy the Python executable to Contents/Resources/. Not 
>> sure what
>>   to do about a Framework python, though. Not sure I even care about 
>> that
>>   anymore: it only seems to make thing harder here. What do you think?
>
> I think the framework python is still my preferred option, and I hope 
> we can get Apple to adopt it at some point in the future. but for the 
> time being I want to keep both working.

I don't understand the benefits of the framework build.   It requires 
additional maintenance within the Python source trees and doesn't seem 
to add any capabilities that couldn't be done with a 'regular' build of 
Python?   I would think there is a tremendous amount of value in 
eliminating the number of differences between the build of Python on 
one platform vs. others.  Certainly, the Mac platform warrants the slew 
of Mac specific modules that are in their, but modules build relatively 
cleanly without requiring changes to and ongoing maintenance of 
configure.in....

I admit a lot of ignorance on this front-- emphasis on ?

....

>> - A strip binaries option. Hm, evil? Could save a huge amount of disk 
>> space,
>>   though.
>
> Good idea. But: is "strip" available if you don't have the dev tools 
> installed?

It is in /usr/bin/strip and, I believe, is a part of the BSD layer, not 
the dev tools.  Should definitely check the BOMs in 
/Library/Receipts/....

b.bum