On 1 Apr 2009, at 00:28, David Ayers wrote:
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:
On 31 Mar 2009, at 20:00, David Ayers wrote:
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.
Are we? What platforms currently have no support for either ffcall or
libffi, but do have support for __builtin_apply()? (Note the last
condition; the further you get from Linux/x86, the less likely
__builtin_apply() is to actually work)
(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.
Neither am I, but no one on the GCC side seems to be working on
Objective-C. I tried to persuade the FreeBSD port maintainer to
enable ObjC++ recently in the default build, and his reaction was that
ObjC was basically unmaintained in GCC and ObjC++ was in an even worse
state.
Someone at Apple created some patches over a year ago for adding
support for properties to GCC on the GNU runtime. Are they merged
yet? No. Is anyone planning on merging them, or rewriting their
functionality? Not as far as I can see. Do any of the GCC folks
outside of Apple give a dam about Objective-C? Not that I can tell;
we had a /stable/ release ship generating errors with any Objective-C
program containing constant strings a while ago, and the GCC response
was 'Objective-C is not a priority'.
If we continue to treat GCC as our main compiler then run the risk
that we are depending on a project which has no interest in
maintaining the features we need. As far as I can tell, the only
reason ObjC is even included in the default builds for GCC is so that
the FSF can keep that page telling everyone how great the GPL is
because it got GCC its ObjC front-end and ignoring the fact that the
code they got was horrible, unmaintainable, and completely useless
until someone wrote a libobjc implementation (which ended up being
more code than the compiler front end).
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.
From the mailing list when I asked this last, and from comparing the
list of supported platforms for the two. Again, can you name one
platform supported by ffcall and GNUstep, but not libffi? Does anyone
want to jump in and say 'My platform doesn't support libffi! Please
don't drop support!' or is this all hypothetical?
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.
Currently, the GPL exemption for GNU libobjc only applies to code
compiled with GCC. If we compile GNUstep with any other compiler,
then this exemption does not hold. Since new versions of the runtime
are GPLv3, this means we can't, for example, link PopplerKit (GPLv2-
only) with it, and we can't link (for example) LuceneKit (Apache
license) against the older GPLv2 version.
GNU libc has a different exemption, which does not specify the
compiler. I was told a year ago that GNU libobjc would move to using
the same exemption, once the phrasing was worked out for the GPLv3.
This will allow libobjc to be used in exactly the same way GNU libc is
currently used.
If this change isn't going to happen, then there is not much point
working to support the GNU runtime with clang and, since there is
little chance of GCC ever adding new features to Objective-C, there is
no point in my adding new features (properties, non-fragile ivars) to
GNU libobjc.
David
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
