David Ayers wrote:
Hi,
ScriptKit
* Library/Guile.h: Use qualified <gnustep/guile/header.h> path for
inclusions. Use "" rather than <> for local inclusions.
* Library/GuileInterpreter.h: Use "" rather than <> for local
inclusions.
* Library/GuileScript.h: Ditto.
* Library/SKInterpreter.h: Ditto.
* Library/SKScript.h: Ditto.
* Library/GuileSCM.h: Use qualified <gnustep/guile/header.h> path
for inclusions.
Just look at this. Aren't these headers installed eventually? So they would need to keep the <> inclusion for that.
Yes the are installed, but that doesn't mean that they have to use <ProjectIncludeDir/header.h>. They can use "header.h".
This is because...
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/cpp/Include-Syntax.html#Include%20Syntax
|#include "|file|"| This variant is used for header files of your own program. **It searches for a file named file first in the directory containing the current file**, then in the same directories used for |<|file|>|.
So, if I want to *use* a ScriptKit header, my project would:
#include <ScriptKit/gg_Object.h>
this contains:
#include "gstep_guile.h"
which would be searched for in the same directory in which gg_Object.h was found.
This might even speed up the preprocessing a bit, as it doesn't need to go through the -I paths. I think this should be the general technique. I'm sure Apple used to do the same for Foundation.h (except they used import instread of include. I'd be surprised if they don't anymore. I believe why most people do not use this technique is because they are either not aware of it, or they fear ambiguity about which header is included, when the don't qualify the path. This can only happen if the file didn't exist. But that just a bug in my view. If you prefer, I have no problem reverting it before I commit.
Cheers, Dave
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
