Re: GNUstep base almost builds with clang

[David Ayers]

Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:
> On 31 Mar 2009, at 20:00, David Ayers wrote:
> 
> > 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)
> 
> I'd agree with this.  -forwardForProxy:selector:argFrame: is not part  
> of OpenStep.  I don't know if it was part of OPENSTEP 4.2 or WO - my  
> impression was that it was a private GNUstep method that had since  
> been superseded by the ffi stuff.

Indeed... and I don't mind removing forwardForProxy:... as long as we
can continue to support -forward:: for those archs that still still work
with it...unless we officially want to deprecate support those archs.

> > 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...
> 
> Reading the GCC and GNUstep lists, __builtin_apply() and friends are  
> in the 'it may work, but if it stops working randomly then don't be  
> surprised' category.  Every time someone asks a question about them on  
> the GCC lists, the reply seems to be 'don't use them unless you  
> absolutely have to'.
> 
> I am only proposing that we deprecate bits of GNUstep that are not in  
> code paths that are used in the standard configurations and have not  
> been for several years, including some parts that contain comments  
> indicating that they probably don't work.

OK, but the consequence is deprecating platforms.  And that should be
stated and communicated as such.  I'm not too fond of doing that without
very good reasons.

> > (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.)
> 
> This is one of the reasons I want to get clang supporting GNUstep.  C+ 
> + support in clang is still very immature, but it is improving at a  
> rapid pace, and Apple has several people working on it full time.   
> Because it uses a unified parser, the Objective-C++ front end supports  
> everything that C++ one does. All we need to do to be able to make use  
> of this is ensure that the CGObjCGNU class is implemented correctly.

Well I'm not too fond of yet another compiler/runtime to support... but
if it is what apple will be using and it will also replace the current
apple runtime, I'm glad someone is working on it.  But I think will need
insure that our current main compiler / runtime stays in (or is restored
to) a decent condition.

> I'd suggest modifying the configure script.  The ffcall implementation  
> doesn't work safely with EtoileThread, since it does not provide a  
> mechanism for preventing the invocation from trampling over a random  
> stack address if it lasts longer than the call frame.  When I reported  
> this, there was talk of deprecating ffcall, since there don't appear  
> to be any platforms where GNUstep and ffcall work but libffi doesn't.   
> I would suggest that for the next release we require libffi and see if  
> anyone complains.

Where do you get the information that "there don't appear to be any
platforms where GNUstep and ffcall work but libffi doesn't"?  IIRC
peoples mileage varies.  But indeed we need to start documenting which
works with which.

> >> ... 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.)
> 
> Has anyone heard anything from the FSF about relicensing the GNU  
> runtime?  It is currently GPL with an exemption that only applies if  
> code is compiled with GCC.  I was told about a year ago that it would  
> be moved to the same exemption as libc (which allows linking of any  
> code), but haven't heard anything since then.  I'm not really  
> interested in working on adding Objective-C 2 support to the GNU  
> runtime until this change has taken place.

Just to be clear, I highly doubt (and I wouldn't support) a re-licensing
of the GNU runtime as a whole.  I was merely suggesting dual-licensing
the files which you'd like contribute yet retain under an MIT license.

But currently the release of GCC 4.4 is still pending due to the wording
of the runtime licenses.  I'm not sure though that what you wish for
will be part of the language.  Yet for /your/ contributions, the FSF
grants you the right to reuse and re-license those.  Of course you'd
need that right from all contributors to freely use any code in the
library.

/me is the camp of those who do not believe that the freedom to deny
others freedom is actually freedom but a dangerous right.  But I respect
the wishes of contributors who have a different POV which is why I'd
support the exception for the abstraction layer you referenced.

Cheers,
David