Re: Porting autogsdoc to OSX

[Lars Sonchocky-Helldorf]

>On Tuesday, February 26, 2002, at 05:31 PM, Adam Fedor wrote:
>
>> Since we are talking about a limited number of files (in this case, 
>> only autogsdoc, and the XML parser files), and at least autogsdoc files 

>> always have '#include <Foundation/Foundation.h>', we could put in 
>> something like
>>
>> #ifdef MACOSX_COMPATIBILITY
>> #import <Foundation/Foundation.h>
>> #else
>> #include <Foundation/Foundation.h>
>> #endif
>
>Well, I read through the archive (as Nicola proposed) and now do 
>understand the problems with #import. The above proposal would certainly 
>be feasible in the example of autogsdoc, but then again every GNUstep 
>application would have to use such a construct in order to maintain Mac 
>OS X compatibility - not that desirable I guess. Isn't there a better 
>way to do it? (One that could convince more people to adopt such a 
>mechanism)
>

I filed a bugreport on this:

radar #: 2868753, Cocoa headers not protected against multiple #include.

26-Feb-2002 08:23 PM Lars Sonchocky-Helldorf:
* TITLE/SUMMARY
Cocoa header files are not protected against multiple #include like for 
instance:

#ifndef SOME_HEADER_INCLUDE
#define SOME_HEADER_INCLUDE
        //actual header code is here
#endif /* SOME_HEADER_INCLUDE */

This makes some code uncompileable under Mac OS X. You should change this 
since the use of #import is deprecated. (I am referring here to a 
statement of an Apple employee:
<citation>
Search Result 1Von:Stan Shebs (shebs@apple.com)
Betrifft:Re: [OT] Re: import 
Newsgroups:gnu.gnustep.discuss
Datum:2001-12-21 16:20:38 PST 

Pascal Bourguignon wrote:
> 
> The #import  CPP directive is defined  as including a  given file once
> ever in a  compilation run, and that's enough to  be an improvement to
> #include.

You're casually assuming that "a given file" is a well-defined
concept.  In the presence of symlinks, relative paths, and multiple
-I directives on the command line, that's just not true.  In fact,
correct implementation of #import requires looking at inodes to
verify identity, which is not portable because inodes are a Unix
thing.  (I have a patch in Apple's GCC that does this for some
pathological cases that occur in OS X code, needs to be cleaned
up for FSF submission still.)

I think what happened with #import is that it was originally intended
to be a genuine interface-loading construct, but somewhere along the
way it got turned into an intelligent #include.  #import <classname>
wouldn't have the file identity issue of #import <filename>, because
there is only one global space of classes, and behind the scenes you
could have a database of classes for the compiler to look in.  Alas,
although everybody pays lip service to the idea that each #imported
h corresponds exactly to a single class interface, in practice lots
of non-class bits get slipped in, and so we're back to being just a
dialect of C, with #import being like #include, but flakier.

Stan 
</citation>

* STEPS TO REPRODUCE
not applicable

* RESULTS
the sources don't compile

* REGRESSION
not applicable

* DOCUMENTATION
not applicable

* NOTES
not applicable

>Cheers,
>
>   Marcus

greetings, Lars