CODEWITHSUNDEEP
c++
Nathan Ridley
Nathan Ridley

Reputation: 34396

Most common C++ project directory structure convention with respect to third-party libraries

I'm kind of new to C++ (learning some game programming stuff) and I want to set up my directory structure using common conventions. My main point of confusion, which I haven't seen a clear recommendation for, is where I put dependencies. For example, I'm going to be looking at FreeGLUT and FreeType. The first thing I've downloaded is the MSVC build of FreeGLUT and it comes with a subdirectory structure like so:

bin/
    freeglut.dll
    x64/
        freeglut.dll
include/
    GL/
        someheaders.h ...
lib/
    freeglut.lib
    x64/
        freeglut.lib
readme.txt

The C# developer in me wants to create a subdirectory called "Dependencies" within my solution directory, take all of this and put it in its own subdirectory there, and then do the same with any other libraries, similar to the NuGet packages directory, then reference the appropriate locations when building. I'm not 100% sure but I'm guessing this might be messy with regards to referencing header files if they're scattered throughout different subdirectories, given that you don't just "Add References" in C++ like you do in C#.

Should my dependencies be part of my project? Should I break them out into different base folders? What's the standard thing to do?

n.b. I understand that lib or dll is a choice (i.e. you don't use both in your build)

Upvotes: 2

Views: 2740

Answers (1)

Krzysztof Kosiński
Krzysztof Kosiński

Reputation: 4325

The more-or-less standard solution is as follows:

  1. In your main source control repository, you store only the source files and the build system files required to compile them. No binary dependencies at all.
  2. If the dependencies are nontrivial to obtain and install, make a secondary repository and put the dependencies there.
  3. If you need to use an external library with some modifications and upstream won't accept them, either put its complete modified source tree into your main source control and integrate its build process into the build process of your application (in-tree fork), or store the modified source in yet another repository (out-of-tree fork). Note that if you use an in-tree fork, most licenses will require you to make your program open source. With others, e.g. LGPL, you can just publish the source code of the out-of-tree fork.

This is what e.g. the Inkscape project does: there is a main repository at https://launchpad.net/inkscape with the complete source code of the project, and there is a separate repository at https://launchpad.net/inkscape-devlibs with the binaries of the dependencies required to build under Windows.

This way you will avoid cluttering up the revision history with dependency changes and storing large binary files in your main tree.

Upvotes: 2

Related Questions