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