[Top][All Lists]
[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!
- Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers, David Ayers, 2004/03/19
- Re: Legacy applications and headers, Adam Fedor, 2004/03/19
- Re: Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers, Helge Hess, 2004/03/19
- Re: Legacy applications and headers,
Nicola Pero <=
- Re: Legacy applications and headers, Marcus Müller, 2004/03/19
- Re: Legacy applications and headers, Helge Hess, 2004/03/19
- Re: Legacy applications and headers, Nicola Pero, 2004/03/19
- Re: Legacy applications and headers, Adam Fedor, 2004/03/19
- Re: Legacy applications and headers, Nicola Pero, 2004/03/19
- Re: Legacy applications and headers, David Ayers, 2004/03/19
Re: Legacy applications and headers, Markus Hitter, 2004/03/19
Re: Legacy applications and headers, Nicola Pero, 2004/03/19