pyobjc-dev

[Pyobjc-dev] GNUstep PyObjC compatibility

[Alex P. <ap...@st...>]

Ronald et al,

I lurk on the cocoa-dev mailing list, and recently saw a posting about 
PyObjC. Someone in #macpython on FreeNode told me you'd done the bulk 
(all?) of the work to make PyObjC work with GNUstep once upon a time. 
I'm the GNUstep website maintainer (one of a couple of others), and am 
putting together a page with a list of language bindings to demonstrate 
how many languages you can use with GNUstep. I'd love to help you 
resuscitate the GNUstep support in PyObjC and keep it actively working.

I downloaded the CVS sources to PyObjC a day ago and attempted to get it 
to build, to no avail. Someone told me to look in 
Scripts/gen_all_protocols.py and it looks like there are some hardcoded 
paths in there. GNUstep system header files live in a slightly different 
place than they do on OS X. Foundation and AppKit headers are found in 
$GNUSTEP_SYSTEM_ROOT/Library/Headers/Foundation and 
$GNUSTEP_SYSTEM_ROOT/Library/Headers/AppKit, respectively. There are 
also some InterfaceBuilder (our IB-esque app is called GORM) in 
$GNUSTEP_SYSTEM_ROOT/Library/Headers/InterfaceBuilder. GNUstep also has 
a 100% API compatible AddressBook implementation, but it is not part of 
GNUstep proper, and as such may or may not be on any given machine. If 
it is, the headers would be in 
$GNUSTEP_LOCAL_ROOT/Library/Headers/AddressBook .

For those of you who might be wondering, GNUstep lives in various 
places. I have it installed in / so my System folder is simply /System, 
local is /. Most distributions which package GNUstep put it in 
/usr/GNUstep or /usr/lib/GNUstep, which is why we must use system 
variables such as $GNUSTEP_SYSTEM_ROOT et al.

Cheers for now,
Alex Perez
GNUstep.org web team

Re: [Pyobjc-dev] GNUstep PyObjC compatibility

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

On 4-apr-04, at 2:11, Alex Perez wrote:

> Ronald et al,
>
> I lurk on the cocoa-dev mailing list, and recently saw a posting about 
> PyObjC. Someone in #macpython on FreeNode told me you'd done the bulk 
> (all?) of the work to make PyObjC work with GNUstep once upon a time. 
> I'm the GNUstep website maintainer (one of a couple of others), and am 
> putting together a page with a list of language bindings to 
> demonstrate how many languages you can use with GNUstep. I'd love to 
> help you resuscitate the GNUstep support in PyObjC and keep it 
> actively working.

I haven't checked the current CVS version, but several weeks ago the 
core of PyObjC worked with GNUstep. The Foundation bindings were also 
functional, but I didn't port the AppKit bindings.

We've recently done some invasive surgery on the bridge to increase its 
usefulness in multi-threaded environment. This might have broken 
GNUstep support.

>
> I downloaded the CVS sources to PyObjC a day ago and attempted to get 
> it to build, to no avail. Someone told me to look in 
> Scripts/gen_all_protocols.py and it looks like there are some 
> hardcoded paths in there.

It should not be necessary to use gen_all_protocols.py just yet. This 
might be required to add support for GNUstep-specific features, but 
that can wait.

> GNUstep system header files live in a slightly different place than 
> they do on OS X. Foundation and AppKit headers are found in 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/Foundation and 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/AppKit, respectively. There are 
> also some InterfaceBuilder (our IB-esque app is called GORM) in 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/InterfaceBuilder. GNUstep also 
> has a 100% API compatible AddressBook implementation, but it is not 
> part of GNUstep proper, and as such may or may not be on any given 
> machine. If it is, the headers would be in 
> $GNUSTEP_LOCAL_ROOT/Library/Headers/AddressBook .
>
> For those of you who might be wondering, GNUstep lives in various 
> places. I have it installed in / so my System folder is simply 
> /System, local is /. Most distributions which package GNUstep put it 
> in /usr/GNUstep or /usr/lib/GNUstep, which is why we must use system 
> variables such as $GNUSTEP_SYSTEM_ROOT et al.

My development box for the GNUstep box is a debian linux system 
("testing" release). I've also installed SimplyGNUstep on an old PC, 
which has GNUSTEP_SYSTEM_ROOT=/System as well.

The first step to getting a full-featured GNUstep port of PyObjC is to 
get the current port working again (e.g. core module + Foundation), 
adding support for other frameworks should be easy enough.

Now that I have the attention of a real GNUstep developer, I also have 
a question: setup.py currently contains hard-coded CFLAGS and LDFLAGS 
for GNUstep (see line 365 and on in setup.py), is there an easy way to 
extract this information from the GNUstep build environment?

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] GNUstep PyObjC compatibility

[Alex P. <ap...@st...>]

Ronald Oussoren wrote:

> I haven't checked the current CVS version, but several weeks ago the 
> core of PyObjC worked with GNUstep. The Foundation bindings were also 
> functional, but I didn't port the AppKit bindings.

Hm, doesn't seem to now.

>
> We've recently done some invasive surgery on the bridge to increase 
> its usefulness in multi-threaded environment. This might have broken 
> GNUstep support.

Probably :)

>
>>
>> I downloaded the CVS sources to PyObjC a day ago and attempted to get 
>> it to build, to no avail. Someone told me to look in 
>> Scripts/gen_all_protocols.py and it looks like there are some 
>> hardcoded paths in there.
>
>
> It should not be necessary to use gen_all_protocols.py just yet. This 
> might be required to add support for GNUstep-specific features, but 
> that can wait.
>
>> GNUstep system header files live in a slightly different place than 
>> they do on OS X. Foundation and AppKit headers are found in 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/Foundation and 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/AppKit, respectively. There are 
>> also some InterfaceBuilder (our IB-esque app is called GORM) in 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/InterfaceBuilder. GNUstep also 
>> has a 100% API compatible AddressBook implementation, but it is not 
>> part of GNUstep proper, and as such may or may not be on any given 
>> machine. If it is, the headers would be in 
>> $GNUSTEP_LOCAL_ROOT/Library/Headers/AddressBook .
>>
>> For those of you who might be wondering, GNUstep lives in various 
>> places. I have it installed in / so my System folder is simply 
>> /System, local is /. Most distributions which package GNUstep put it 
>> in /usr/GNUstep or /usr/lib/GNUstep, which is why we must use system 
>> variables such as $GNUSTEP_SYSTEM_ROOT et al.
>
> My development box for the GNUstep box is a debian linux system 
> ("testing" release). I've also installed SimplyGNUstep on an old PC, 
> which has GNUSTEP_SYSTEM_ROOT=/System as well.

Okay, good. Never ever ever ever ever *ever* hardcode paths WRT GNUstep 
:) You can't be sure of where things actually live, but I'm sure you 
already know that, just stating it for the sake of the others here who 
may not.

>
> The first step to getting a full-featured GNUstep port of PyObjC is to 
> get the current port working again (e.g. core module + Foundation), 
> adding support for other frameworks should be easy enough.

Agreed.

> Now that I have the attention of a real GNUstep developer, I also have 
> a question: setup.py currently contains hard-coded CFLAGS and LDFLAGS 
> for GNUstep (see line 365 and on in setup.py), is there an easy way to 
> extract this information from the GNUstep build environment?

For the record, I'm not on the GNUstep developer team, but I am 
affiliated with them. I don't do much programming myself these days due 
to my hectic academic schedule, but I do help out where I can and when I 
have time. Lately, I've taken to "spreading the word" if you will, and 
that includes being proactive about things when people ask what the 
benefits of using GNUstep are. I just want to add yet another to the 
list :) My primary role is as GNUstep.org maintainer.

In any event, yes,  the -DGNU_RUNTIME=1, -fgnu-runtime, and -lobjc flags 
which are currently hardcoded in setup.py are set as RUNTIME_DEFINE, 
RUNTIME_FLAG, and OBJC_LIBS in the 
$GNUSTEP_SYSTEM_ROOT/Makefiles/library-combo.make file. This is not an 
executable shell script,  and is not set by default. Since GNUstep runs 
on a plethora of platforms, it uses its own make system typically, which 
is just pasted on top of GNU make. There are a number of  ifeq's in that 
file. The one that is by far the most common is the "ifeq 
($(OBJC_RUNTIME_LIB), gnu)" statement, in which the aforementioned 
variables are set. Additionally, in 
$GNUSTEP_SYSTEM_ROOT/Makefiles/Additional/base.make, there is a line, 
'AUXILIARY_OBJCFLAGS += -fconstant-string-class=NSConstantString' which 
sets the GCC constant string class flag. Finally, in 
$GNUSTEP_SYSTEM_ROOT/Makefiles/library-combo.make, there is a line which 
says "FOUNDATION_LIBRARY_DEFINE = -DGNUSTEP_BASE_LIBRARY=1" You should 
be able to parse what you need out of those files.

If you have any more questions or would like me to try anything out, let 
me know.

Cheers,
Alex Perez

Re: [Pyobjc-dev] GNUstep PyObjC compatibility

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

The version I just checked in mostly works on GNUstep again (only the 
core bridge and Foundation have been ported as of yet). I haven't run 
any real code, just the unittests.

What worries me is that Scripts/runPyObjCTests shows 2 failures in 
Foundation.test.test_nsdata and Foundation.test.test_nsdictionary that 
are not present when the tests are run seperately. This is probably a 
bug in PyObjC.

Another odd thing is this message: 'Unable to retrieve information 
about SIGPIPE'. This is shown when I import objc.

(GNUstep on a Debian 'testing' box, python == python2.3, gcc == 
gcc3.3.3)

BTW. The current CVS version does not work with Python2.2, due to 
extensive use of PyGILState_Ensure combined with giving up the GIL when 
calling into Python.

Ronald