resolving relative #include statements

Hi...

I'm re-organizing on some of my projects, and I've run into an odd case.
It's making me think that relative #include statements will match not only
relative to the code doing the including but also if there is any relative
match applied to any of the directories in the project's
AdditionalIncludeDirectories. Is this correct?

E.g. if your project has AdditionalIncludeDirectories="..\..\overhere", then a
#include "..\Foo\Bar.h"
in your code will find the include at either
..\Foo\Bar.h
or
..\..\overhere\..\Foo\Bar.h

I have a .h file that has
#include "../3rdPartySource/zlib121/zlib.h"

in it. Now, that directory/library was never one up and over from where
this .h or vcproj were living. The actual location of the zlib.h was
../../3rdPartySource/zlib121/zlib.h

In the AdditionalIncludeDirectories in the vcproj, I had
AdditionalIncludeDirectories="..\include;..\..\3rdPartyBin"

I was thinking the project compiled before because 3rdPartySource and
3rdPartyBin are peers, so
..\..\3rdPartyBin\..\3rdPartySource\zlib121\zlib.h
was the include file found.

Thanks
Mark

changliw
Wed Jan 09 02:00:01 CST 2008

Hi Mark,
For your question, please see the answers inline:
> I'm re-organizing on some of my projects, and I've run into an odd case.
It's making me think that relative #include statements will match not only
relative to the code doing the including
> but also if there is any relative match applied to any of the directories
in the project's AdditionalIncludeDirectories. Is this correct?

Yes, sure! You analysis regarding the relative include path was correct.
Additionally the compiler will also search your environment PATH
directories and VC++ "Include files" directories if it could not search the
file in the current project directory. The difference is that the
directories in environment PATH variable and the VC++ "Include files" are
on a global level for all VC++ projects while AdditionalIncludeDirectories
is a setting for single project.

Did you encounter any issue when you use such including means? If so,
please feel free to let me know.

Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

changliw
Fri Jan 11 06:37:17 CST 2008

Hi,

I am interested in this issue. Would you mind letting me know the result of
the suggestions? If you need further assistance, feel free to let me know.
I will be more than happy to be of assistance.

Have a great day!


Best regards,
Charles Wang
Microsoft Online Community Support

======================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

Tim
Fri Jan 11 23:02:19 CST 2008

Mark <mmodrall@nospam.nospam> wrote:
>
>I'm re-organizing on some of my projects, and I've run into an odd case.
>It's making me think that relative #include statements will match not only
>relative to the code doing the including but also if there is any relative
>match applied to any of the directories in the project's
>AdditionalIncludeDirectories. Is this correct?

Yes. This shouldn't really be much of a surprise. There's no difference
in searching between
#include "xxx.h"
and
#include "..\..\xxx.h"
The compiler will look first relative to the directory that contained the
file with the #include, and then relative to each of the directories in the
includes list and %INCLUDE% variable.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.