Organising .libs in a codebase of several C++ projects

Question

Let's say you have several bespoke C++ projects in separate repositories or top-level directories in the same repository. Maybe 10 are library projects for stuff like graphics, database, maths, etc and 2 are actual applications using those libraries.

What's the best way to organise those 2 application projects to have the .libs they need?

• Each lib project builds the .lib in its own directory, developers have to copy these across to the application area manually and make sure to get the right version
• Application projects expect lib projects to be in particular paths and look for .libs inside those locations
• A common /libs directory is used by all projects
• Something else

This is focused on C++, but I think it's pretty similar with other languages, for instance organising JARs in a Java project.

Answer 1

I'd suggest this approach:

Organise your code in a root folder. Let's call it code.

Now put your projects and libraries as subfolders (e.g. Projects and Libraries).

Build your libraries as normal and add a post-build step that copies the resulting headers and .lib files into a set of shared folders. For example, Libraries\include and Libraries\lib. It's a good idea to use subfolders or a naming convention (myLib.lib, myLib_d.lib) to differentiate different builds (e.g. debug and release) so that any lib reference explicitly targets a single file that can never be mixed up. It sucks when you accidentally link against the wrong variant of a lib!

You can also copy third-party libraries that you use into these folders as well.

Note: To keep them organised, include your files with #include "Math\Utils.h" rather than just "Utils.h". And put the headers for the whole Math library into include\Math, rather than dropping them all in the root of the include folder. This way you can have many libraries without name clashes. It also lets you have different versions of libraries (e.g. Photoshop 7, Photoshop 8) which allows you to multi-target your code at different runtime environments.

Then set up your projects to reference the libraries in one of two ways:

1) Tell your IDE/compiler where the libs are using its global lib/include paths. This means you set up the IDE once on each PC and never have to specify where the libs are for any projects.

2) Or, set each project to reference the libs with its own lib/include paths. This gives you more flexibility and avoids the need to set up every PC, but means you have to set the same paths in every new project.

(Which is best depends on the number of projects versus the number of developer PCs)

And the most important part: When you reference the includes/libs, use relative paths. e.g. from Projects\WebApp\WebApp.proj, use "..\..\Libraries\include" rather than "C:\Code\Libraries\Include". This will allow other developers and your buildserver to have the source code elsewhere (D:\MyWork instead of C:\Code) for convenience. If you don't do this, it'll bite you one day when you find a developer without enough disk space on C:\ or if you want to branch your source control.