Re: where did objc-gnu2next.h go?

[David Chisnall]

On 25 Aug 2010, at 09:30, Fred Kiefer wrote:

> If I remember correctly, this file was removed by David or Richard.
> (Most likely David as I could not find an entry in the ChangeLog file
> stating the removal :-)

I thought this was me too, but in fact:

$ svn log -v Headers/Additions/GNUstepBase/
...
r28774 | rfm | 2009-10-04 15:26:07 +0000 (Sun, 04 Oct 2009) | 2 lines
Changed paths:
...
   D /libs/base/trunk/Headers/Additions/GNUstepBase/objc-gnu2next.h
...
$ svn log -r28774
------------------------------------------------------------------------
r28774 | rfm | 2009-10-04 15:26:07 +0000 (Sun, 04 Oct 2009) | 2 lines

a bit step towards removing obsolete mframe code.

------------------------------------------------------------------------

If you then look in the ChangeLog[1], you see these two logs on this day:

> Remove lots of obsolete code as part of the ong term process of scrapping the 
> old mframe stuff.

and:

> Use NSInvocation functionality directly rather than duplicated versions of 
> the code in ffi/ffcall/mframe specific files.  Should simplify things and 
> make maintenance easier.


Above this is a list of files, not including objc-gnu2next.h [2]

Looking at the file, it seems to do a half-arsed job of implementing the GNU 
runtime APIs on top of the NeXT runtime.  The GNU runtime APIs are crufty and 
horrible, and I've deprecated or removed all of them in libobjc2, so using them 
is not a sensible thing to do if you want portable code. 

We now provide an almost complete implementation of Apple's runtime APIs from 
10.5 on both the GNU runtime and in libobjc2, so these should be used in 
portable code.  If you need to support older GNUstep versions, you can just 
grab ObjectiveC2.framework from inside base and link this with your own app 
explicitly.

All of the non-portable runtime APIs in libobjc2 now have a _np suffix, so you 
know not to use them if you care about supporting OS X.  In contrast, the GNU 
runtime had a nasty habit of using functions with the same names as the NeXT 
ones but subtly different semantics or arguments.  

David

[1] The obligatory rant about how the ChangeLog is a waste of time because you 
have to go via svn blame or svn log to find the bit that you actually want to 
read in the ChangeLog, and it only associates metadata with dates, rather than 
with revision numbers (so you don't know which one is the relevant commit 
message), can be taken as read, I hope.

[2] So can the rant about how the ChangeLog requires developers to remember to 
manually track stuff that svn tracks automatically.