Is it common to include a specific build of a library/ tool for production level project?

Question

I am working with C++ in a Linux/ Unix environment. I am trying to learn the physical design of large scale projects. In one of my projects, I am using an SDK from a camera manufacturer. They released a new version of this SDK and one of the applications I had built based on the previous version stopped working because the SDK had undergone some restructuring and changes. I fixed this by making changes on my code. This was not production level code and was only for research.

Recently I came across another project that had a folder for a specific gcc-build inside its root directory. When I checked the CMakeLists.txt, it looked like it was setup to use whatever tools where available inside this folder.

1. In the first case, should I have configured my cmake and other associated tools to ensure that the right version of SDK was shipped (to other researchers)? It looks like I could have used either of the two approaches here:

   1. Use a script that ensures that a specific version of SDK is downloaded and installed prior to building my code. Ensure that the user runs this script in their system.

   2. Grab all the library files I need from the SDK and provide it inside my project folder, asking cmake to use specifically these files.

   Which of the two is the right approach? If it is the second approach, do the SDK library files go in lib directory inside the project root folder?

2. In the second case, is it a bit extreme to include a specific gcc-build? Or is it a common practice to ensure that things don't break?

3. In the case of shared library files, doesn't keeping and shipping separate copies partially beat the purpose of having shared libraries? Isn't one of the ideas to use one set of files throughout the system and avoid shipping bulky code?

Answer 1

Is it common to include a specific build of a library/ tool for production level project?

I would say it is at least not totally uncommon, and it depends on how you define "production level". But if you try to achieve 100% reproducible builds which don't break when third-party dependencies change in unpredictable ways, you have to version all artifacts and build tools by yourself.

Of course, if you have certain trust that a vendor of the component will provide older versions, and specifically the version required by your software over its full life time, then the "download & install script" solution may be sufficient. Nethertheless I would recommend to archive all tools in the correct version at least for yourself, so you can provide them later to someone who has problems downloading something from a 3rd party vendor.

For example, your case (1): are you 100% sure your camera vendor provides "the right version of the SDK" long enough? In a place which is stable enough a download script will find it automatically, even in, lets say, 3 years? Or maybe it does not matter, since your research period where this specific software is used is much shorter?

Or let us look at your case (2): on this page, one can find old GCC releases from more than 20 years ago, so there can be certain trust that one can get an older version if required. But when you see how challenging it can become to get the right combination of compilation tools together (see True Crypt, for example), providing the complete toolset as a whole may be a good idea also, especially for projects of a certain complexity.

This depends also on the kind of project you have in mind: the requirements for an Open-Source lib which is intended to be compiled by several GCC versions may be quite different from the requirements of a closed-source, commercial product which must be maintained over several years, maybe to fulfill some contract.

And to your question (3): disk space is cheap, and saving resources by having each shared lib only once in a system is usually not worth it. Working software which uses resources not fully optimally is definitely better than non-working software with optimal resource usage.