gnustep-dev
[Top][All Lists]
Advanced

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

Re: Legacy applications and headers


From: Nicola Pero
Subject: Re: Legacy applications and headers
Date: Fri, 19 Mar 2004 16:51:39 +0000 (GMT)

> Personally (from a lF point of view) I don't care about the patch, its 
> a speed optimization for OSX and has no significant effects on 
> compilation performance on ix86/Linux platforms.
> Obviously the way it is now is technically correct (#ifdef 
> NeXT_Foundation_LIBRARY), because this optimization only applies to 
> Cocoa, but I see ZNeK's point about configuration and think that it is 
> valid.

I slightly disagree :-) ... This is a speed optimization for GNUstep :-)

I think the main concept is: 


#ifndef GNUSTEP

 /* This is the portable way which works on all systems.  */
# include <Foundation/Foundation.h>

#else

 /* This is the code optimized to compile faster on GNUstep.  */
# include <Foundation/NSArray.h>
# include <Foundation/...>
# include <...>

#endif


So I think GNUSTEP is a nice define to use in this case.

It's particularly nice because every system (current or future) which is
not under our control will use #include <Foundation/Foundation.h> which is
the only construct which works on all *step platforms.  (On Apple,
Foundation headers are not protected against multiple inclusion, so
#include <Foundation/NSArray.h> does not work at all).

If we are under our control, using gnustep-make and gnustep-base, only
then we are picky and include headers selectively to get more compile
performance on GNUSTEP.

Said that, I don't think this is a particularly important matter :-)



> Summary: the proper solution would be a "-DGNUSTEP_WITHOUT_PCH=1" 
> define generated by the gstep-make configure script (this would also 
> take into account that even gstep-base might have a PCH compiler in the 
> future!). Until this is available the __APPLE__ define is probably the 
> best match to the original intention.

And yes you have a point with gnustep-base getting a PCH compiler, but I'd
ignore this complication for now.

But you reminded me that I need to look at the new PCH support in GCC, and 
on how we have gnustep-make automatically take advantage of that!





reply via email to

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