Re: #import vs #include

[Nicola Pero]

> *SIGH*
> > Yep the G stands for GNU and the problem with #import is that it 
> > is/was depricated (from gcc). But I don't know what the current/future 
> > state of gcc will be. If the #import will be valid or that we still 
> > need to use #include and ifdefs.
> In GCC 3.4 #import *IS UNDEPRECATED* We really need to pull together 
> and clarify that in our documentation, IMO. Personally, I'd vouch for 
> --enable-import being on in GNUstep-make by default in light of this 
> FACT,

Pedantically speaking ;-), this is not very important: when #import is
undeprecated, using -Wimport or not using it on the compiler command line
does not make any difference.  So, --enable-import or --disable-import
gives the same result: the compiler lets you use #import without
complaininig. :-)

Said that, 

> and also that all documentation which contains this kind of FUD 
> be changed to reflect this new reality.

I agree with you that we should remove/mitigate documentation against
#import.

As a last remark (out of the quarrel, just on practical terms), don't
forget that #include + include guards is expected to be compiled faster
than #import.  How much faster, and/or whether that's relevant in
practice, is up to experimentation (and might depend a lot on the
filesystems you are using; I'd expect/hope that with all sources on a
normal linux filesystem you wouldn't almost see any difference in speed);
I've never seriously experimented with it.