0

Is there any way to safely include libraries (either internal or external) in the directory of a project (say in a lib/ folder) when you ship or release code? As far as I can see it would be a lot easier if the library files the application depended on were placed there; that way, other people wanting to use the code wouldn't have to download, compile and install the libraries on their own system (in the /usr/local/lib folder or likewise). If this is possible (or advisable), then other people could then just git clone the entire directory including the libraries, something like cmake could set the linker to pick up these libraries and the users could then just issue a cmake and make command rather than have to install the libraries on their system first.

I'm sure this might not work if the two machines have a different byte order or word length, but excluding these, is there any reason not to just put the .a or .so files in with your code?

If it is not possible (or recommended for some reason) to include the library files with the source code then are there any alternatives to having the other user download, compile and install them on their own machine? Containers (Docker) or dependency managers (Conan) perhaps?

p.s. I'm talking about c/c++ development in linux environments exclusively for desktop applications.

Improve this question
4
  • I guess the best approach would be to use some package manager, like the one you mentioned (Conan). Then, you create and host your repository with your libraries (they could be publicly available or not). Versioning .a or .o is not feasiable, since GIT relies on text files to perform diffs.
    – Emerson Cardoso
    Commented Aug 25, 2017 at 20:40
  • I see.. so although it wouldn't be a good idea to store any binary/object/library files on git, for the reason you have just mentioned, it may still be beneficial to keep these libraries stored in a centralised place (such as Artifactory) and ship them with the code - rather than have the user's linker try find them somewhere in their own root directory?
    – AndyM
    Commented Aug 25, 2017 at 20:51
  • I think so. Other possibility is to have your repository to point to other repository that contain you third-party lib`s source, and when you build your project you also build all of your dependencies before. Open-source projects like chromium do this.
    – Emerson Cardoso
    Commented Aug 26, 2017 at 16:50
  • You could include the source code of the libraries with your project. For example, if your project uses SDL, and you don't want your users to need to install that separately, just include it internally in your project as a subproject.
    – Brandin
    Commented Aug 27, 2017 at 8:05

1 Answer 1

Reset to default
1

If the dependencies are popular (such as ffmpeg), they can usually be deployed through apt-get or yum. This is a de facto standard way of deploying dependencies, and have a benefit of being scriptable (so you can include a script within your source which installs those dependencies). If the dependencies are not so popular, they may still be available through a third-party repository. This requires additional operations, but they can be added easily to the script.

If you're talking about the libraries which are not available as stand-alone products, then a package manager is indeed an excellent alternative. In some communities, those package managers became standard (npm for Node.js, pip for Python, etc.) Being unfamiliar with C++, I haven't used Conan, so you may check if among the alternatives, the one you'll use will be the most popular one.

Do not include third-party libraries in your repository. Among other problems:

  • It makes the installation unnecessarily complex and non-standard.
  • Somebody will have to handle a case where the dependency is already installed on user's machine, including an older or a newer version (both situations being very tricky to handle).
  • It increases the size of your source code.
  • Every time a new version of the third-party library is released, you have to update the whole source code (if you store it as source) or a bunch of binaries (if you store the binaries) in your repository. Compare it to a simple change of version in the file containing the list of third-party packages.
Improve this answer
4
  • You have outlined some very good reasons not to include third-party libraries with releases. One of the reasons I thought it might be a good idea to try ship code with dependencies included is that package managers (such as apt-get) might install a version of the dependency that is ahead of the one used for development which could lead to compilation/linkage errors for the user, but I guess it is the responsibility of the developer to maintain compatibility with their dependencies.
    – AndyM
    Commented Aug 25, 2017 at 21:07
  • Not necessarily. When running apt-get, you can specify the version to install.
    – Arseni Mourzenko
    Commented Aug 25, 2017 at 21:49
  • Keep in mind as well that repos may not always have the newest version available.
    – Matthew
    Commented Aug 25, 2017 at 23:22
  • @AndrewMurtagh Versioning dependencies is difficult however you do it. If you bundle your dependencies and there's a security update for one of them, will you push out that update to your users? Apt/yum will handle that for you. The *.so libraries use a naming scheme that indicates binary compatibility so minor updates shouldn't break anything. OTOH their major versions may be years old, in which case you'd need to bundle libraries to use more recent features.
    – amon
    Commented Aug 27, 2017 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.