This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FSF GCC, #import and #pragma once


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]