Re: GNUstep base almost builds with clang

[David Ayers]

Hello David,

Am Dienstag, den 31.03.2009, 17:49 +0100 schrieb David Chisnall:
> On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:
> 
> > On 30 Mar 2009, at 16:37, David Chisnall wrote:
> >
> > I *think* (iirc) a little of the code in mframe is used for some  
> > NSMethodSgnature features.  It may be that we always need that part  
> > compiled in, but it should be possible to separate out what we need,  
> > and only build the rest of the code if we don't have libffi or ffcall.
> 
> Using the power of grep, I see:
> 
> NSMethodSignature uses some mframe stuff for parsing type encodings.   
> This doesn't really make sense being in mframe.m, since it's nothing  
> to do with creating call frames.
> 
> NSConnection uses them in -forwardForProxy:selector:argFrame:, which I  
> believe is deprecated since all of the argframe stuff was deprecated  
> years ago and never worked correctly, and in a few places with #ifdefs  
> so they're not actually compiled.

I'm mostly concerned about keeping support for deprecated API which was
1) part of either the OpenStep specification.
2) part of OPENSTEP 4.2 (widely distributed cross platform
implementation of OpenStep)
3) part of WebObject 4.5 (last cross platform implementation of
OpenStep)

If we can implement the argframe approach (ie. -forward::) via libffi
then we could also resolve some long standing libobjc issues.  Yet I'm
still unsure if it can be done at all.

I'm also a bit concerned about statements like "I believe ...[some
code]... never worked correctly" as we simply do not know who is using
it and whether it works for production code.  Mostly one finds out that
things stopped working when it's too late...  (For example currently it
seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't
maintaining it anymore, and I hardly know anything about c++ to be of
much use here... I'm am trying to takle some of the objc/libobjc bits.)

What I'd /really/ like to see is that we would start setting up our
"Test Farm" to also run the test suite and possibly get something like:
http://gcc.gnu.org/wiki/CompileFarm
running for "Supported Platforms".  But even if we had access to such a
farm, I don't really have the time to volunteer to maintain it.

> NSInvocation.m uses them in the fall-back code for when ffcall and  
> libffi are not present.

I think we should deprecate the fallback and log a message asking users
who stumble over it to post their architecture/platform information.
The goal would be to find someone who could implement libffi support for
that architecture/platform.

> NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment().
> 
> The stuff for decoding type strings should probably be pulled into a  
> separate file.

Indeed... I think I once started a patch to extract mframe_next_arg into
GSObjCRuntime.m under a different name.  I'm not sure anymore what
happened to it.  But I agree that this function shouldn't need any of
the code in mframe.m itself.

> >> objc-gnu2next.m uses them in a function that is deprecated on the  
> >> legacy Apple runtime and not supported by the modern Apple  
> >> runtime.  Does anyone actually use next_objc_msg_sendv()?
> >
> > I don't but it's always dangerous to assume that nobody else will.   
> > On the other hand, that's old enough that we might insist on people  
> > changing.  The next major release will need to break ABI  
> > compatibility for 64bit code in order to be compatible with Apple's  
> > recent changes, so now is probably a good time to introduce other  
> > cleanups that break the ABI in little-used or unused ways.
> 
> This function seems to be part of an attempt to reproduce the old NeXT  
> runtime API.  More recently, I've been working on implementing the  
> ObjC 2.0 runtime API (supported by Apple for both their new and old  
> runtimes) on top of the GNU one.  You can see the current version here:
> 
> http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/
> 
> At some point, I'd like to push this up to GNUstep[1] and have the  
> Apple runtime APIs properly supported.  Now that Apple has deprecated  
> posing and defined a stable public API for the runtime, I would  
> imagine a lot of programs are going to start using it.
> 

I think the proper place to put this is FSF libobjc.  I'd support a
request to dual-license the respective files.  (Not that I have any real
clout but if we as a project request it, maybe are chances are not that
bad.)

> [1] If possible, I'd like to keep the MIT license for these files so  
> they can be easily used outside of GNUstep as well, since they are low- 
> level and have potential applications for Objective-C code that does  
> not use GNUstep.

Cheers,
David