#include <filename.h> broken in VC7

[Bill Roper]

Did you know that the #include directive when using angle
brackets works substantially differently in VC7 than it
did in VC6?

It used to be that the reference for the additional
include directories that you specify for the project
started from the project directory. Now it appears to
start from the directory that you're including the file
from. So if you have a directory structure like this:

Client
Server
Admin

where there are shared files at the Client level, your
include paths simply don't work. As a result, we're going
to have to completely reorganize our directory tree and
lose a substantial amount of productivity for a few days
while we fix this mess.

This wouldn't be so bad, except we're dealing with another
bug that MS has acknowledged, but not yet fixed, which is
generating a massive number of bogus warning messages
*and* which is why we didn't notice this problem until now.

Add that to the fact that our programmers are in a full
revolt over the new interface, and you start to wonder why
we bothered to upgrade.

(BTW, the search function in the newsgroups doesn't work
either, so I have no idea whether anyone has reported this
or not.)

 

[Tarek Madkour [MSFT]]

Did you know that the #include directive when using angle
brackets works substantially differently in VC7 than it
did in VC6?

It used to be that the reference for the additional
include directories that you specify for the project
started from the project directory. Now it appears to
start from the directory that you're including the file
from. So if you have a directory structure like this:

Client
Server
Admin

where there are shared files at the Client level, your
include paths simply don't work. As a result, we're going
to have to completely reorganize our directory tree and
lose a substantial amount of productivity for a few days
while we fix this mess.

Bill - I can't seem to reproduce the problem you are
describing. The build system invokes the compiler from the
project directory. In your example, the compiler command-line
for a file in the "Server" directory should be something
like:

CL Server\filename.cpp /I. /allothercompileroptions

This way the compiler should find your include files that
live in the project directory.

What is the compiler command-line in your build log? That
should provide a clue on what could be going wrong.

Also, you can always use project macros (e.g. $(ProjectDir))
to eliminate any problems caused by relative paths. You do not
need to restructure your directories.

Thanks,

 

[Bill Roper]

-----Original Message-----

Bill - I can't seem to reproduce the problem you are
describing. The build system invokes the compiler from the
project directory. In your example, the compiler command- line
for a file in the "Server" directory should be something
like:

CL Server\filename.cpp /I. /allothercompileroptions

This way the compiler should find your include files that
live in the project directory.

What is the compiler command-line in your build log? That
should provide a clue on what could be going wrong.

Also, you can always use project macros (e.g. $(ProjectDir))
to eliminate any problems caused by relative paths. You do not
need to restructure your directories.

Well, you see that would be the problem.

The Server project includes some files that are in the
Client directory, one level above. In earlier versions of
VC++, when we compiled the Server project, the Include
paths were *relative to the Server directory* regardless
of where the physical CPP file was located.

Now, the Include paths are relative to the location of the
physical CPP file, not the project that is being built.
Since these files contain:

#include <resource.h>

they're retrieving the resources from the wrong project.
Hilarity ensues.

As I said, the behavior is clearly different from earlier
versions of the compiler and -- as far as we can tell --
not what is documented, nor the way that angle brackets
*should* work on an include.