Re: [Pyobjc-dev] A bit of a mess....

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

On Monday, Feb 24, 2003, at 16:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Sunday, Feb 23, 2003, at 03:59 US/Eastern, Ronald Oussoren wrote:
>> On Saturday, Feb 22, 2003, at 23:39 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> This seems like a big mess and is only going to get worse over time. 
>>>   It also-- I would think-- hampers GnuStep support in that not all 
>>> of the frameworks are available under GnuStep or, if there, are 
>>> completely different.
>>
>> The current situation doesn't really hamper GNUstep support, setup.py 
>> checks if frameworks are present before building the support modules. 
>> The right solution would probably be to move the scripts in 
>> Modules/Cocoa/scripts to the toplevel scripts directory and integrate 
>> them into setup.py. That way we'd automaticly wrap only those items 
>> that are supported on a system.
>>
>> Let's move the script first and worry about the side-effects of 
>> calling them from setup.py later.
>
> OK;  will do.   I'm going to move the scripts, make sure everything 
> works, then commit.
>
> At some point, I would like to move to invoking the scripts that 
> generate the various *.inc files to within setup.py.   This would make 
> supporting 10.1 easier and will make supporting 10.3 easier, assuming 
> new API (safe assumption).

Great. Of course this only works if the new functions were not manually 
wrapped. As an example, if 10.1 didn't have NSCountWindows rebuilding 
the .inc files won't help. We can probably work around this by making 
use of MAC_OS_X_VERSION_MAX_ALLOWED and simular definitions.

>
> It is also probably time to go with FFI only support?   As you have 
> noted, there are still differences between FFI and non-FFI bridge 
> behavior and the lot of us has had difficulty keeping the two 
> straight.   There are also FFI only features now [classAddMethods()] 
> and will likely be more in the future.

Is anyone using non-FFI builds (except the poor souls stuck with 0.8 
(-; )?. I seldomly use or test non-FFI builds, mostly only when I want 
to make sure if a bug is caused by libffi or not.

I'm in favor of dropping the non-FFI support, first only register.m and 
when test_methods.py is more complete I'd even drop 
execute_and_pythonify_objc_method.

>
> I don't know if it is possible to support libFFI with GCC 2.95 [on X 
> 10.1]... at the same time, it seems like we have largely punted on 
> ever supporting 10.1?

I think 10.1 support is simular to GNUstep support: Unless someone 
steps up to actually implement and maintain the support it is highly 
unlikely that we'll ever get around to doing it.

>
>>> If we are going to fix this, we should do it now.  Preferably, the 
>>> various framework specific modules should be encapsulated in their 
>>> own directories.   Some of the framework support should potentially 
>>> even be moved out of the pyobjc root source as it is less about 
>>> bridging to the core of ObjC and more about bridging a specific 
>>> framework's worth of functionality.
>>
>> Just like in Lib there should be one directory for every supported 
>> framework in Modules. I don't want to move frameworks from the pyobjc 
>> source tree unless supporting them cost too much time or someone 
>> steps up to maintain them in a seperate distribution.
>
> Ok -- I would also like to pull the stuff in AppKit/ into two new 
> directories;  Cocoa/ and Foundation/.   AppKit *really* should be 
> renamed Cocoa.  Even if Cocoa is only a cosmetic name in OS X [try 
> class-dumping the Cocoa.framework -- it contains nothing], we ought to 
> stick w/Apple's nomenclature as much as possible...

The documentation still refers to AppKit, I don't think that calling 
the wrapper for AppKit.framework Cocoa would be very helpfull. If we do 
add a Cocoa module it should basicly be just this:
	from Foundation import *
	from AppKit import *

Ronald