FSF GCC, #import and #pragma once
David Ayers
d.ayers@inode.at
Tue Jul 22 22:32:00 GMT 2003
Personally I think it is rather unforunate, that these discussions all
come down to this bickering.
We have the rather unfortunate situation of having two seperate ObjC
implementations. Unlike the rest of GCC, Apple is able to licensing
thier runtime under a none GPL compatible license, and they do,
implicitly indicating that they are not interested in merging it with
the FSF's implementation. As in most cases of multiple "vendors", ObjC
is in need of a specification, as not only this discussion is showing.
The document Apple has may be a good start but as you say, it's
insufficient, and it is proprietary.
I greet Nicola's offer of writing a proposal for specification, under a
license that could be included in the FSF's GCC documentation. This can
only happen meaningfully though, if we work on this together. Our goal
won't be to make the FSF's ObjC incompatible to Apple's ObjC. The goal
must be to provide a "Free as in speech" specification that hopefully
will lay the ground work for a "Free as in speech" unified ObjC
implementation. There is a /potential/ conflict of interest, but when
acting as maintainers for the FSF's GCC, please put on you FSF hats.
Now on the subject matter at hand, I personally would plea for not
removing support for #import. Not because it's well enough defined or
portable enough, but merely to enforce software freedom. If #import
were removed from FSF's implementation, the hurdle to make a software
project, which is currently propriatary, a free project, is just set
another technical notch higher. No matter how bad the implementation
is, as long as it's compatible with Apple's GCC, the FSF GCC should
support it, especially if Apple would keep it in sync with thiers until
we unify. Of course the warnings about it's problems should remain
right in the developers face by default.
Cheers,
David
More information about the Gcc
mailing list