[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting autogsdoc to OSX
From: |
Lars Sonchocky-Helldorf |
Subject: |
Re: Porting autogsdoc to OSX |
Date: |
Tue, 26 Feb 2002 19:41:52 +0100 |
>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
- Re: import vs include Re: Porting autogsdoc to OSX, (continued)
- Re: import vs include Re: Porting autogsdoc to OSX, Dirk Theisen, 2002/02/27
- Re: import vs include Re: Porting autogsdoc to OSX, Nicola Pero, 2002/02/27
- Re: import vs include Re: Porting autogsdoc to OSX, Dirk Theisen, 2002/02/27
- Re: Porting autogsdoc to OSX, Adam Fedor, 2002/02/26
- Re: Porting autogsdoc to OSX, Marcus Müller, 2002/02/26
- Re: Porting autogsdoc to OSX, Pascal Bourguignon, 2002/02/26
- Re: Porting autogsdoc to OSX, Helge Hess, 2002/02/26
Re: Porting autogsdoc to OSX, Lars Sonchocky-Helldorf, 2002/02/26
Re: Porting autogsdoc to OSX, Lars Sonchocky-Helldorf, 2002/02/26
Re: Porting autogsdoc to OSX,
Lars Sonchocky-Helldorf <=