[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
- Re: XML idea, (continued)
- Re: XML idea, Kazunobu Kuriyama, 2004/01/09
- Re: XML idea, Helge Hess, 2004/01/08
- Re: XML idea, Richard Frith-Macdonald, 2004/01/09
- Re: XML idea, Pete French, 2004/01/08
- Re: XML idea, Alex Perez, 2004/01/08
- Re: XML idea, Nicola Pero, 2004/01/08
- Re: XML idea, Alex Perez, 2004/01/08
- PortabilityKit (was: Re: XML idea), Chris B. Vetter, 2004/01/09
- Re: Portability/Compatability between GNUstep <---> Cocoa..., thisguyisi, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Richard Frith-Macdonald, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa...,
Kazunobu Kuriyama <=
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Richard Frith-Macdonald, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Kazunobu Kuriyama, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Richard Frith-Macdonald, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Fred Kiefer, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Kazunobu Kuriyama, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Alex Perez, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Kazunobu Kuriyama, 2004/01/12
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Nicola Pero, 2004/01/13
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Richard Frith-Macdonald, 2004/01/13
- Re: Portability/Compatability between GNUstep <---> Cocoa..., Nicola Pero, 2004/01/13