discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Portability/Compatability between GNUstep <---> Cocoa...


From: Kazunobu Kuriyama
Subject: Re: Portability/Compatability between GNUstep <---> Cocoa...
Date: Mon, 12 Jan 2004 22:50:47 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Richard Frith-Macdonald wrote:

For both base and gui, MacOS-X extensions are intermingled with the rest of the code, and there are compiler preprocesssor values used to control #ifdef statements in the headers so that application programmers can decide whether their software builds with MacOS-X and GNUstep extensions available or not (the default is for all extensions to be available to the application code).

I'd like to know this point more. As far as I know, there are two compilation switches STRICT_OPENSTEP and NO_GNUSTEP for the purpose stated above. The implications of '#define STRICT_OPENSTEP' and '#define NO_GNUSTEP' are trivial, but that of '#if !defined STRICT_OPENSTEP' or '#if !defined NO_GNUSTEP' looks
fairly ambiguous.

(Also, I'm skeptical about allowing application programmers to use of marcos designed for internal use
of library development.  But this is another issue. )

Recently, I've made some non-trivial programs based on some Cocoa programming books and found some concrete incompatiblilities between GNUstep and Cocoa. When I come across such an incompatibility, I'm always at a loss because GNUstep doesn't provide any preprocessor macro which can be used just for differentiating GNUstep code and Cocoa one. I feel both STRICT_OPENSTEP and NO_GNUSTEP or their
negations are not appropriate for that purpose.

Is there already any macro, or an established idiom (i.e. GNUstep conventions) for the purpose?

If not, I think it would be better for us to have a certain macro predefined in GSConfig.h, say __GNUSTEP_LIBRARY__, to distinguish GNUstep's headers from those of Cocoa.



I'd like to put "bad" MacOS-X extensions in another subdirectory and mark their use as not being recommended for style/simplicity reasons. However, nobody has contributed any code in this category yet.

I agree to this idea. But is there anyone who contributes something if it is considered "bad"? :)

- Kazunobu Kuriyama





reply via email to

[Prev in Thread] Current Thread [Next in Thread]