Re: includes/imports in gui.

[Nicola Pero]

> 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).


When I implemented precompiled headers in gnustep-make, I planned to  
immediately modify gnustep-gui to use them.  And I did.  But then I  
discarded the work as the speed-up
was too little to be worth the extra effort and complexity - not to  
mention all the users for whom the build would be slower because their  
compiler doesn't have working precompiled
headers ... eg, GCC 4.1 users!. :-(

Just to clarify the background - a precompiled header is specific to  
the exact flags you pass to the compiler.  If you change any of the  
compiler flags, you'll need a new
precompiled header.  As a consequence, precompiled headers are  
generally used by having the project you're building (eg, gnustep-gui)  
have a file with all the #imports in it,
and then precompile that file as part of the compilation of the  
project; all files in the project then include that header as the  
first thing they do.

So, precompiled headers initially slow your build by adding an  
additional step ... creating the precompiled header.  That step can't  
be parallelized because it needs to happen
before all the other ones.  Depending on how much using a precompiled  
header speeds up the following steps, it's worth it or not.  If you're  
compiling a lot of files, and
importing lots of large system headers in all these files, it's  
generally worth it (the more you parallelize, the less it's worth).

But in the case of GUI, it's not worth it because it's only using  
Foundation.  So it'd be only #importing Foundation/Foundation.h.  In  
my tests it really starts
to be useful when you include at least both Foundation.h and AppKit.h.

Finally, most older compilers don't support precompiled headers, and  
GCC 4.1 has broken precompiled header support so gnustep-make  
automatically disables
precompiled headers if you're using GCC 4.1 (for a sad example, I am  
using GCC 4.1).  In these cases, you'll simply get a (slightly) slower  
build as you're including
more headers than needed and they are not even precompiled.

So, switching to importing Foundation/Foundation.h and precompiled  
headers would slow building gnustep-gui for a large group of users  
(who don't have a working precompiled
header support in the compiler), would not significantly speed up  
builds for everyone else, and adds extra complexity.  The current  
system of importing the headers we need from
gnustep-base gives us consistent, fairly fast and simple builds, so I  
wouldn't change it. ;-)

Thanks