15

I have a project which uses 3-4 different open source C/C++ libraries.

I built these libraries for several platforms and checked in include files and static libs for different platforms in my project.

However, I struggle with a couple of problems. All of these projects are around dependency management. And I am looking for best practices advice.

1) How do I know what exactly do I use?

I don't have a way go get a version of a static lib. As result, I need somehow track which version of static lib I am using (may be SHA of a commit from which it was built)?

This is especially important when I need to figure out when to upgrade these libs.

2) How do I reproduce the build?

I could have struggled to build some specific library for a specific platform. It took me a while to figure it out.

The next time when I will need to build the same library could be in a half year (when I will need to upgrade for whatever reason. However, by that time, I won't definitely remember anything and an environment on which it was built will be long gone.

3) Should I fork these libraries to have a copy of source code?

This is a lesser concern. However, it's still a concern. It's nice to make sure that builds are reproducible (and that kind of requires source code).

Victor Ronin
  • 629
  • 1
  • 5
  • 14

2 Answers2

5

Do you really need to always use an exact version of a dependent library? Is it badly written/does it break it's API with every minor increase in version?

If you look at open-source projects, their build (configure part mostly) scripts check whether various libraries are present and throws an error if not. It is also flexible enough to allow the user to link against a newer version of the library (which probably provides more bug/security fixes than an older one) and also doesn't enforce static or dynamic linking.

If you truly need reproducible builds, then you should also pay attention to the exact version of the compiler and it's standard libraries, perhaps even the operating system. In this case, having a build machine with the exact environment that you require is, in my opinion, better than checking in compiled libraries in the source code repository.

D. Jurcau
  • 537
  • 4
  • 8
  • 2
    I don't think that I need to use exact version. However, I need to know which one I am using. As example, if somebody finds that OpenSSL 1.1.0b has huge vulnerabiity, I better know whether I use OpenSSL 1.1.0b or 1.1.0c – Victor Ronin Dec 29 '16 at 18:24
  • Regarding a build reproducibility, that's probably my secondary concern. – Victor Ronin Dec 29 '16 at 18:24
3

How do I know what exactly do I use?

If the include files or libs files do not contain a version number already, add a text file "version.txt" (containing the version number) by yourself to each lib folder and check it into your VCS, together with the lib and include files. However, if you version the full source of the lib (point 3), chances are high there is already a source code file containing the version number, so no need to maintain your own for this case.

How do I reproduce the build?

Try to automate as much as you can. Use scripts, makefiles, or files of your favorite build tools. Put this all under source control. If there are manual steps required, write the details down into a text file (for example, readme_build.txt) and put that under source control as well.

Should I fork these libraries to have a copy of source code?

You should have a copy of the source code, but fork only if necessary (for example, if you stumble over an urgent bug, and the original author cannot fix it within your time contraints). Or, if the authors use a different compiler environment than you, and it is necessary to make some changes to make the lib work in your environment. However, be aware that each change to the original source code in your fork most probably makes it harder to integrate updates at a later time.

Nevertheless I recommend to get a copy of the original (unforked) source code of the libs you are using. That will allow you to fork or maintain the lib later if it becomes necessary, even if the original maintainer decides to revoke the lib sources from the public web.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • So, the answer is "do this manually" :) I was hoping that somebody will say... oh... there is a tool for that :) When you say "copy of the source code" you mean, just get a tar file with the source and dump it in source control? – Victor Ronin Dec 29 '16 at 18:23
  • 1
    @VictorRonin: no, the answer is "let your VCS handle all it can do for you", and "automate as much as you can using standard build tools". You are the one who picks a specific version, and you are the one who needs to defines the build steps, link & include references for your environment. The standard procedure for manifesting these despendencies is through scripts, makefile, project files etc. – Doc Brown Dec 29 '16 at 19:44
  • ... and how you get the lib or the libraries source code depends on how the maintainer/vendor provides it. Maybe a tar ball, maybe by direct access to git hub, maybe a nuget package. – Doc Brown Dec 29 '16 at 20:16