[OGo-GNUstep-Port] GNUstep define

[Nicola Pero]

On Tue, 15 Jul 2003, Filip Van Raemdonck wrote:

> Hi,
> 
> I assume this list is about building OpenGroupware.org with "regular"
> GNUstep environment instead of the one in ThirdParty?
> 
> I've been trying to do that last friday, and this evening. I've had to
> make a few changes here and there, especially about including certain
> header files or not including them - mostly about Foundation Extensions.
> Now currently I'm using #if(n)def GNUSTEP to mark such changes; however
> AFAICT that is defined by NGExtensions which is from OGo and not GNUstep
> which makes it a chicken and egg problem while building NGExtensions
> itself (I just removed or altered conflicting code blocks there) and also
> requires the NGExtensions to be included to actually work.
> 
> Since my knowledge of GNUstep is not all too extensive, does anyone with a
> better knowledge of it than me know of a #define which is GNUstep specific?

There seems to be some confusion here.  GNUSTEP *is* a GNUstep specific
#define. :-)

The theory is that GNUSTEP is a GNUstep specific #define, and is #defined
by gnustep-base to let the code know that gnustep-base is being used
(check core/base/base.make).  Which makes sense after all.

It's unfortunate that NGExtensions/common.h is #defining GNUSTEP too.  
Maybe it was used in the past if the software was built without
gnustep-make, to make a difference between the two ?  Anyway, I suggest
renaming that #define to something else as a start, to prevent conflicts.  
I can't really change the #define of GNUSTEP inside gnustep-base both
because there is a lot of software outside my control using that #define,
and because after all it makes more sense that GNUstep itself #defines
GNUSTEP :-)

My suggestions for changes in this area are to standardize the #defines
used to the ones automatically defined by gnustep-make when compiling,
documenting the options, and using them consistently in all the code.

In practice, I'd suggest -

 - use GNUSTEP (or GNUSTEP_BASE_LIBRARY) to check that gnustep-base is 
used.

 - use LIB_FOUNDATION_LIBRARY to check that libFoundation is used.

 - use NeXT_FOUNDATION_LIBRARY to check that Cocoa FoundationKit is used.

 - use NeXT_RUNTIME and GNU_RUNTIME to check the ObjC runtime which is
being used.

I personally think that supporting the original NeXT runtime / NeXT
foundation library is not worth the effort, and that we should better try
to support the Apple Mac OS X runtime / foundation library properly, but
I'm Ok with supporting it if people want to.

I can add a #define APPLE_FOUNDATION_LIBRARY in gnustep-make if it seems
more appropriate than NeXT_FOUNDATION_LIBRARY when compiling on Apple Mac
OS X (that would be in addition to, not as a replacement of,
NeXT_FOUNDATION_LIBRARY not to break code using NeXT_FOUNDATION_LIBRARY to
check for non-GNU foundation libraries;  I know it makes difficult to make
a difference between Apple and NeXT foundation library, but is that really
important ?  who's using NeXT nowadays anyway ? ;-) )

I'd keep NeXT_RUNTIME because that is the official name which is also used
in GCC's command line switches; newer GCC also predefine __NEXT_RUNTIME__
when using the NeXT ObjC runtime.  I'd stick with this terminology, so I'd
prefer not to define APPLE_RUNTIME.

Let me know if you have any problems with these #defines.

Else, I'd suggest to stick with this list of #defines, and to revise all
OpenGroupWare code so that it consistently uses these #defines, and only
these.

Of course the #defines should be defined by gnustep-make (and additional
makefiles installed in gnustep-make), not by OpenGroupWare itself.