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