Project paths made easy with environment variables

Introduction
I don’t know about you, but I get very frustrated when I just want to use a library. I don’t feel like setting up the paths for every project that uses the library. I just want to get in there, and start coding. This makes the problem a lot easier to deal with and saves a lot of time. This is probably obvious for most developers, but I didn’t figure it out until I started installing a bunch of libraries and SDKs, and then it “clicked” for me what they were doing and why it’s so much better. I used to think that anytime the install directions said to modify or add an environment variable, it was just going to be a big hassle, so I never did it. Boy was I wrong!

Purpose
If you have a project that requires an SDK or a library to be installed, there’s a good way to go about setting it up in your project, and a bad way. The good way is to set up an environment variable to the directory with the SDK or the library installed. The reason this is a good idea is because you don’t have to have any absolute path information in your visual studio / make file solutions. So when you install the dependency/SDK, you also set up an environment variable to the location it’s installed. Some SDK’s do this automatically for you, which is nice. If your project is cross platform, this will save you and your users (if they want to recompile your code) a lot of frustration and avoids having “special case” logic in your make files.

Pitfalls
If you think that the solution is to simply use relative path names in the project/solution, you’re wrong. The SDK could be installed anywhere on a different person’s machine, particularly if it’s a cross platform project. Using the environment variable approach also alleviates having to distribute the SDK with your project as well (if you chose to use relative paths). As long as your project doesn’t depend on a very specific version, this approach is better.

Summary
So basically, you set up the environment variable that points to the SDK/library, and you reference the environment variable inside your project or cmake files.

Example
So, let’s say you downloaded this new SDK and installed it into C:\SDKs\awesome_sdk. Inside of the awesome_sdk directory, you will probably have folders such as “bin”, “include”, “libs”, etc.

So now, just create an environment variable called “AWESOMESDK_DIR” that contains “C:\SDKs\awesomesdk”. Now, within your project, cmake, or premake files, you set up the include directory to point to $(AWESOMESDK_DIR)\include. You do the same with the libs. You also probably want to add $AWESOMESDK_DIR\bin to the $PATH environment variable as well. The “bin” directory probably contains .dll files and possibly other tools. This will allow you to run the executable regardless of the directory, and will also prevent you from polluting your system32 directory with various dlls. Obviously, you’ll have to distribute the dll’s with the .exe when you’re finished though.

Now, when someone downloads your sources / project on their computer, they can install the dependency SDK anywhere they like on their own machine. Your project that they downloaded is smaller because it doesn’t include the dependent SDK. As long as they set up the environment variable properly, when they go to build the project/solution, it should build without any project changes.

There is one thing left that you may want to do. Depending on the development tools that you’re using, there is usually a way to do this “globally”. What I mean is that it’s possible to only have to do this once, and every project that you make, from here on out, will automatically be using the new SDK, automatically. For example, in visual studio 2010, you go to the “Property Manager” tab and right click on “Microsoft.Cpp.Win32.user” and click “Properties”. This property page will inherited for all projects that you make from here on out. Setting up the include directory to be $(BOOST_DIR)/include on this property page, will mean you never have to set it up, for any project, ever again! Of course, your situation may change depending upon whether or not you use CMake or premake or something like that.

References
Setting up an environment variable in Windows
Setting up an environment variable in linux

Leave a Reply

You must be logged in to post a comment.