Sign in to follow this  
bzroom

The most ideal way to setup a large project with lots of dependencies

Recommended Posts

When creating a game or any other project which has multiple library dependencies such as boost, directx, physics libraries, etc. What is the best way to structure both your file structure and the project settings, specifically for visual studio. The project setup should be easy to deploy to any other person with an existing dev environment and also to brand new dev machines. Some questions: Should the libraries be placed along side the project itself so that their version will not interfere with the version of the libraries used for other projects? Or should they all be stored in a common place, disconnected from the project itself? I ask this because what if my project is dependent on a particular version of a library and I want to deploy my project to a machine which has these libraries but is dependent on another version for other projects. I wouldn't want my version dependency to break the other machines projects. But it seems silly to have multiple versions (possibly even the same version) of the library on the same machine. One thing I do like about having the libraries stored with the project is it makes it easy to use relative folder paths in the project properties. If you need to deploy the project you can package up all the libraries and the code and send it off and you know it'll build without requiring the new dev to have his enviornment setup a particular way. Which basically brings me to the next question, should project dependencies for common things such as boost be specified at the IDE or the project level? I mostly always do the project level but when creating new projects it becomes a chore to always include the same ol' libraries such as boost, when they're common between everything that I do. Another area of interest, slightly more specific to my project, and a lack of knowledge on my part, when you have a hierarchy of projects, such as an engine which depends on a physics engine, which depends on a math library, how exactly should the project settings look? I'm always confused wether any of those libraries (.lib projects) actually need to link in their dependent libraries or if all the dependencies should be linked in by the end user. In other words, do my linker settings for the engine need to include the physics.lib, or should my game.exe be the one who realises that it needs to link both engine.lib and physics.lib? Same for something like boost. Do I need to link boost into all those libraries, or just the final exe? This has always been a bit of an ambiguous topic for me and unfortunately I basically just add the dependencies until I can get it to build, without much rhyme or reason. I'd like to do things the right way. Well that's enough typing for now. Could someone please explain how they'd configure their folders and project settings for an example of a solution which had an Application.exe project which depends on an Engine.lib project, which depends on a Physics.lib project, all of which depend on boost? Oh just remembered something. I heard that for the project dependencies, specifically the linker ones, that just choosing the project as a 'Project dependency' is sufficient and that you dont actually have to add DependentLib.lib to the linker libraries, that VS will do that for you. Thank you.

Share this post


Link to post
Share on other sites
It depends on what type of source control you're using. If you have an advanced source control system like ClearCase, complicated library management such as what you describe becomes trivial.

In the absence of ClearCase, however, what I've done is the following:

a) Check all the library binaries and headers into source control under a repository location that is not affected by branching. I call this place sandbox.

b) Organize sandbox similarly to the following:


sandbox
|--src
|
|--boost
|
|--openssl
|--include
|
|--boost
|
|--openssl
|--win-x86
|
|--boost
| |
| |--1.39.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| |--1.40.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
|--openssl
| |
| |--0.9.8k
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| |--1.0.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
|--win-x64
|
|--boost
| |
| |--1.39.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| |--1.40.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
|--openssl
| |
| |--0.9.8k
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| |--1.0.0
| | |
| | |--vc9.0
| | | |
| | | |--Debug
| | | |
| | | |--Release
| | |--vc10.0
| | | |
| | | |--Debug
| | | |
| | | |--Release





Then, using visual studio property sheets, I create property sheets such as the following:


Library version constants
-------------------------
Global property sheet that contains user macros such as the following:
$(UseBoostVersion) = 1.39.0
$(UseOpenSslVersion) = 0.9.8.k
$(ToolsetVersion) = vc9.0

Debug
-------------------------
Define preprocessor settings such as _DEBUG, DEBUG, optimization settings, etc


Release
-------------------------
Define preprocessor settings like NDEBUG, optimization, etc


x86
-------------------------
Create a user macro $(PlatformCode) = x86

x64
-------------------------
Create a user macro $(PlatformCode) = x64


UseBoost
-------------------------
Define include path to sandbox\include\boost
Define library path constructed from $(PlatformCode), $(ConfigurationName), $(BoostVersion), and $(ToolsetVersion)


UseOpenssl
-------------------------
Define include path to sandbox\include\openssl
Define library path constructed from $(PlatformCode), $(ConfigurationName), and $(OpenSslVersion), and $(ToolsetVersion)


There are some disadvantages to this approach, but short of having a source control system that is as flexible as ClearCase is, I haven't found a better way to deal with the issue of some projects sharing certain library versions and other projects sharing different versions of the same library.


The advantages are that upgrading a library is trivial. You only need to change 1 property sheet and every project in your entire solution automatically uses the new library. Also that developers never have to build their own libraries.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this