Handling external C/C++ code libraries in a Github repository

Question

Short version:

For projects that require external libraries, how could I keep the dependent libraries with a project in the same Github repository? Would a sub-module of the source code be best? Or should the corresponding .lib, .a, .dll, etc files be uploaded as part of the project? Or should it even be in the repository at all?

This isn't meant to be a subjective question, the long version explains more in-depth

Longer version:

I'm working on a C++ project with Eclipse as the IDE that requiring various external libraries as dependencies.

I would like to host this project on GitHub so that it will be easier to keep track of changes. Ideally I would like it so that if I switch computers I can just clone the repo without having to re-download and recompile some of the dependencies for my platform. This would also allow other people to work on it without them having to get the same versions of each library as well.

I know that most of the current libraries I'm using exist as source code on GitHub, which means I could include them as sub-modules in my repository. The only issue with this is that it likely wouldn't provide the required corresponding .lib, .a,.dll files that are needed for linking.

My other thought is to just include the libraries inside the project in the repository, like so:

assets/
|- ...
src/
|- ...
framework/
|- library1/
|  |- include/
|  |- lib/
|  |- bin/
|- library2/
|  |- include/
|  |- lib/
|  |- bin/
...

So that the libraries will easily be easy to reference in Eclipse, because it would just be ${ProjName}/framework/library/.... But I feel like this isn't good practice because of how much it will bulk up the project -- however that's just my opinion and possibly wrong.

Am I right in my thinking to include the libraries as part of the project itself? Or is there another way that is commonly done to simplify this process?

Answer 1

Use git-repo to maintain multiple projects, as the same way Android source codes are maintained.

Each sub-module can be a full git repository, where the binaries are compiled/linked in the default folder of each project repository folder. In this way, you can keep track of each public or your private sub-module/sub-project.

As for the directory structure, just pick whatever you like. When you define your git-repo collection to match your directory structure, it will work just fine.