Sharing a project in heterogeneous environment

Question

Here is a situation:

You have a project (for example Visual Studio solution with multiple projects)
Project relies on various environment variables, libraries, tools and other dependencies.
You have to share this project (via source control repository) across multiple developers. Developers don't have similar environment (e.g. libraries live in different places, etc.) for various reasons.

How would you deal with inconsistency?
Would you enforce developers to have similar environment?
Do you use some kind of configuration scripts?

EDIT:
Most of you are talking about paths (include dirs etc.) but it's only one part of a complex problem. Maybe some of you used some kind of configuration scripts or some project migration tool? Also, Visual Studio was mentioned as an example. It would be nice to have IDE-agnostic recommendations.

Answer 1

I would support a default environment, but allow developers to keep a custom one, but not checked into source control. Shell Scripts/Batch Files; that sort of thing.

Answer 2

If you use Visual Studio you can easily setup include paths etc using relative directories. e.g. You may want to include a folder of shared header files in the project settings. Just do this:

Additional Include Directories: "$(SolutionDir)....\Shared\Includes"

That way it doesn't matter where the project is on the dev's machine, as long as they check out the full source control branch from the repository, it will work just fine.

Answer 3

Make use of project variables! If you have set up the projects environment variables correctly then you wont run into problems with directory includes.

Read up on project property files at here

Answer 4

@Bernard I'm interested more in how to make life easier for those developers. It's a daunting task to setup project settings each time you check it out from source control system.

Answer 5

We try and enforce a similar environment as much as possible, but also use locally defined environmental variables to allow some variation. For example in the location of library files using the CV++ Directories options. We also use a post build perl script to allow different or multiple target locations

Answer 6

besides the file paths i also include in the repository a lib folder with all the dll, ocx, whatever files that are required to build the source.

plus in a vstudio project i add the references from this lib folder.

i recommend http://www.codeplex.com/treesurgeon to create this development tree

Answer 7

Thats what I like so much about maven for our current java development. Depency managment, and project file initiation and build automation works like a breeze.

Answer 8

@aku:
You can keep local files that aren't in source control. They don't get removed every checkout or something.