I have recently moved to VS2012 and up until now have used windows environmental variables in my include paths (%DEV% = D:\Dev)

Don't do that!!

The correct answer is to set up your own system's environment variables so that when you do, say, #include <sdl.h> or whatever (sorry if it's not a real header - I don't know SDL, it's just an example) the compiler then looks in your $PATH environment variable and tada! Header found. Same goes for the libraries (.lib, .dll, ..). Then you and your friends set them differently depending on where your stuff is on your computers, yet <sdl.h> will always be found correctly.

A less intrusive way to do this is to give the locations of the libraries to the compiler via an include path/lib path argument instead, but this is annoying if the project file is included in source control...

Ok, I'll give that a shot. Is there a reasoning why using Path (user variable) rather than a system variable is the better way to go?

Thanks

Well, system variables have a wider scope that user variables, so if a user variable suffices that is what you should use (what if you have multiple users, each of whom use the same compiler? maybe they don't want to have the compiler look for a bunch of libraries you use because it could cause clashes or whatever, again this is probably not the case but *what if*). That isn't really the reason, though, it's just the compiler expects to find external resources in:

1. built-in directories (you can't change this), this is for system headers e.g. iostream, stdlib.h, ...

2. directories specified in the $PATH (this is implementation dependent) and - for most compilers - in a special compiler variable called $INCLUDE

3. directories specified on the command-line (if using an IDE, this is set via your project options under "header/include directories" or something)

4. the current directory (if using quoted includes)

As I said, it's "better" to pass that info to the compiler by modifying your project settings (lowest scope) but isn't ideal when the project file is shared by everyone since you'll end up clobbering each other's settings and you'll have the same problem. A good version control tool can handle that but in your case it may simply be more effective to use environmental variables and forget about it. This is also the case when installing SDK's since they typically insert themselves in the $PATH so you don't need to do anything special.

Using system-dependent variables e.g. %DEV% in headers is not something you should do, because:

1. its behaviour is not really specified by the compiler, making debugging harder (and, as you see, many integrated IDE tools don't play nice with it)

2. it is most definitely not portable (if/when you ever change compilers, or want to port things to another operating system)

In effect, how the path specified in an #include is interpreted is up to the implementation, so relying on it is kind of like "fixing" a broken door using duct tape instead of metal hinges: it will come crashing down on you eventually. It's much better to turn this into well-defined behaviour by using whatever facilities your compiler (or, failing that, your operating system) offers you when it comes to specifying where library files should be found.

I use a similair scheme. I have an environment variable which points to the root of my source files directory.

Then in the project's settings i add the neccessary paths using that env variable to point to the root, and than specify it further down (something like $(DEV)/source for the source files, $(DEV)/lib for the libs etc).

Is this a good setup? Reason i'm using this scheme is because my source files are not located inside my solution dir, but are located elsewhere (per to my needs/liking), since i didn't want to make my source files dependant on a specific IDE setup. Say if i decided to use eclipse for some reason instead of VS2012, i dont have to change my source files directories at all, just add the neccessary paths to eclipse using the same scheme (or similair, haven't looked at how eclipse does it, i imagine it's not so different).