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. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
