Jump to content

  • Log In with Google      Sign In   
  • Create Account


Include paths best practices for mutli-person development


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 rbanke   Members   -  Reputation: 154

Like
0Likes
Like

Posted 13 July 2013 - 11:52 AM

Forgive me if this is not the right forum for this question, I couldn't decide which forum was most applicable.

 

I have recently moved to VS2012 and up until now have used windows environmental variables in my include paths (%DEV% = D:\Dev) this way my partner or others would not necessarily have to keep everything in the same location as long as they had their variables set. Now I'm noticing that IntelliSense is having problems finding those directories. A few searches show that it's been reported but not fixed.

 

What I really would like to know, is if there is a better way to do this than I've done until now? If our projects need DX, SDL, or other libraries, how do you guys include them in a way that is more friendly for multiple people working on the same project?



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8135

Like
0Likes
Like

Posted 13 July 2013 - 07:01 PM


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...


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 rbanke   Members   -  Reputation: 154

Like
0Likes
Like

Posted 13 July 2013 - 09:34 PM

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



#4 Bacterius   Crossbones+   -  Reputation: 8135

Like
1Likes
Like

Posted 13 July 2013 - 09:56 PM

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#5 Nypyren   Crossbones+   -  Reputation: 3674

Like
3Likes
Like

Posted 13 July 2013 - 11:00 PM

Large projects I've worked on include most SDKs within their own directory hierarchy. This also means they get committed to the source control repo. Everything in a project should be set up using relative paths so that each developer can store the project anywhere they want. The project and solution files for the project are checked in. .SUO files and other per-user things like that are added to the ignore list.

Edited by Nypyren, 13 July 2013 - 11:05 PM.


#6 rbanke   Members   -  Reputation: 154

Like
0Likes
Like

Posted 14 July 2013 - 01:30 AM

 

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.

 

 

When I was talking about using a system variable (like %DEV%) i was using that in the projects include path not within the headers. Thanks for the tips!



#7 Strewya   Members   -  Reputation: 1149

Like
0Likes
Like

Posted 15 July 2013 - 02:59 AM

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).


devstropo.blogspot.com - Random stuff about my gamedev hobby





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS