What is the correct way of adding third-party code into a C or C++ project?

Question

I want to incorporate some open source libraries into my C project. This is the first time I do that, so I don't know what is the right or most common way of doing it.

I see two possible paths I can take:

1. Download the code of each library I'll use, add them to my project folder and modify them as I need.
2. Just list each library as a dependency. So the user would download them to its machine and include them to the project with (maybe) some makefile configuration.

I think option #1 is better for two reasons:

1. I release the user from the task of downloading and configuring the dependency.
2. In my project two libraries have overlapping code. Part of one library is a subset of the other. They have the same functionalities and the same identifiers names (variables, functions, #defines). So I would have some conflicts that I don't know how to fix.

But I just think option #1 is better. I really don't know what's the best. Maybe someone knows how to fix the conflicts between the libraries and then my opinion may change. I'm asking this question because I don't know what is the path programmers usually take. I also don't know what are the pros and cons of each alternative. And I also don't know if there are other alternatives.

Update: The expected users are programmers.

Answer 1

@17of26 gave a lot of good reasons why #2 is dangerous, and why #1 makes more sense. But I think there is one thing missing, for which I recommend the following:

• download the code of the library you will use,
• add it to the project folder,
• but don't modify it arbitrarily!!

Avoid modifications if possible. If that is not possible, try to keep the direct modifications down to a minimum and keep everything else in separate files. If necessary, use script files or patch files. So make sure all changes to the libs or to the makefile configuration are documented and can be reproduced.

This gives you a way better chance to update to newer versions of those libs at a later point in time, if needed.

Of course, there will be no guarantee the patches or configuration changes applied to version 1.0 of a lib can be directly applied to version 2.0 of that lib, too. But the chances are the much higher when there are only a few number of patches/changes, and the effort to apply them will be likely smaller.

Answer 2

You always want to package any dependencies with your project.

Your software is going to be built and tested with a particular version of a specific library. It's not guaranteed to work with any other version.

You need to ship your code with that exact version of the library. If you don't, your are opening the door to a support nightmare.

For example, let's say you build and test your code with library Foo v1.0. You don't ship Foo v1.0 with your product and instead say "Hey users, go get this library Foo v1.0".

Now imagine:

• Foo disappears from the internet. Maybe it's hosted by a company that goes out of business. Or maybe the developer of Foo v1.0 gets sick of emails from angry users and removes public access to the library.
• Foo is very actively developed. Foo is now on v8.0. Foo developer decides to stop supporting anything older than v7.0 and removes access to earlier versions.
• Foo developer makes a breaking change to v1.0 but doesn't actually increment the version. Now when users download v1.0, they are getting a different library than what you used and it just doesn't work.

You avoid all of these potential headaches by shipping the exact binaries that software needs to work.

Answer 3

A common way of managing 3rd party code is via "vendor branches" (I assume that you are using some sort of version control system such as git, svn etc).

Vendor branches allow you to keep track of changes to the 3rd party code and easily incorporate those changes into your code along with any changes you need to make to your code to work with those changes.

The subject of vendor branches is too complicated to go into here (and the details would depend on what vcs you are using) but there are many useful guides on the web.

Answer 4

1 is the way to go.

You can add the original source code to your project and the changes you made in a diff patch file.

Then it is easy possible to see the changes you have made and the user will have no problems if the library dissapears from the internet.