gnustep-dev
[Top][All Lists]
Advanced

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

Re: includes/imports in gui.


From: Fred Kiefer
Subject: Re: includes/imports in gui.
Date: Wed, 17 Feb 2010 09:25:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0

Am 16.02.2010 15:53, schrieb Richard Frith-Macdonald:
> I'd like to standardise include/imports in the core libraries ... as
> I've been doing a lot of it in base.
> 
> Previously in base, there was really a bit of a mess ...
> 
> Lots of #includes from they days when #import was deprecated ...
> harmless but annoying

Over the last few years I started to change this in all the gui files I
touched. Perhaps it is the time to be more thorough on this.
BTW the first file I checked in base for the new include style was
NSThread.m and this hasn't been corrected at all :-)

> A mixture of <foo.h> and "foo.h" used ... not harmless ... anything
> using the angle brackets could pick up installed headers rather than
> the local/new versions, which could cause problems for anyone
> building from a new release or from svn.

Angle brackets should only be used for external stuff, that is all the C
headers and of course Foundation headers when used in gui.

> Foundation/Foundation.h used in some places, individual files used in
> others... because Foundation.h imports all the other headers, using
> it while building base would also cause installed headers to be used
> when you actually want local ones.

In gui only a few places import AppKit.h and these have annoyed me for a
long time. These files will be recompiled every time anything changes.

> Two or more files (at least GNUstep.h and GSCategories.h) needed to
> be included/imported by OSX apps wanting to use base additions, and
> some of those headers caused problems it used from within gnustep
> code.
>
> Hopefully, I've now pretty much standardised on #include for C and
> #import for ObjC.

Fine by me, but what do we count as being C? gui currently sees the
config.h file as C and therefore we use #include.


> All source in base should now use quotes rather than angle brackets,
> and avoid Foundation.h so that new builds should work properly on
> systems where base is already installed.
> 
> There should be a single header 'GNUstepBase/Additions.h' for
> software on OSX using the Apple Foundation, and this file should be
> safe to include on GNUstep systems (indded, Foundation.h on GNUstep
> should import it unless NO_GNUSTEP is defined).  Actually, I need to
> re-port the additions library to OSX ... it's currently broken
> there.

At the moment there isn't any gui Addition code that could be use on
OSX, although there are a few classes that would be worth it.

> Anyway, given that gnustep-make and recent compilers have supported
> precompiled headers for some time now, I think gui/back should
> probably simplified to just do #import <Foundation/Foundation.h> 
> (assuming that 'startup' installs base before it builds gui ... so
> the installed Foundation.h will point to all the right code and will
> have a precompiled version to make for fast compilation of gui and
> back).

Here I agree with Nicola. Support for pre-compilation is not that
widespread that we should enforce it. And including Foundation.h instead
of single header files could make compilation slower in some cases. I
think, in this case I will leave the gui includes just as they are, when
we include Foundation.h fine, when it is broken up in single files, fine
as well.




reply via email to

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