CODEWITHSUNDEEP
version-controllibrariescode-organization
gregschlom
gregschlom

Reputation: 4965

Including pre-compiled libraries in source tree

I have a cross-platform C++ project. In this project, we use several third-party, statically-compiled libraries that are quite huge and not easy to build.

Currently, our source tree looks like this:

|
+-3rdparty
| +-include   (initially empty)
| +-lib       (initially empty)
| +-some-library
| +-another-library
|
+-source

When checking out the code, a developer would first build and install "some-library" and "another-library". The install step would put the right files into the include and lib folders, and then they can build our project.

In order to make building our project easier, I was thinking of removing "some-library" and "another-library", and instead just put the includes and the pre-compiled binaries into include and lib folders. This way, a new developper would just have to checkout the project, and build it straight away.

My questions are:

  1. Is it a bad practice to do so? (ie: including precompiled libraries into your source tree).

  2. What potential problems / drawbacks may arise from this setup?

  3. What folder organization you would suggest to account for the several platforms (Windows, Mac OSX, and Linux)?

Additional note: we are using Mercurial.

Upvotes: 0

Views: 863

Answers (2)

Benjamin Bannier
Benjamin Bannier

Reputation: 58594

Good that you are trying to be cross-platform, but bundling dependencies with your source comes with multiple issues.

  • Since you talk about building the dependencies, how do you plan to make sure that the compiled code can run on a developer's machine? I doubt the Windows code will run under Os X, maybe not even the Fedora Linux Rawhide under Debian Linux.

  • If I already have the dependencies installed on my system, how can I cleanly disable installation of your versions? And why would I care to download them in the check out?

  • If you ever plan to get this code into some Linux distribution packagers will bug you about the tight coupling you introduced since your approach is less needed in the Linux world where shared libraries work pretty well.

Of course your approach is followed in a lot of places, big and small, but why should you repeat their mistakes? If you really need to provide your developers with a shortcut to install these dependencies you should write configurable script that installs the dependencies into some prefix. And add some flags to disable installing specific dependencies.

Upvotes: 1

mjfgates
mjfgates

Reputation: 3431

I have worked with version control systems that absolutely refused to keep old versions of binary files. That was a long time ago, and I don't think it's a problem with any current VCS, but check before going live with the idea.

If the third-party library gets updated often, your repository might get pretty big.

Aside from that, I've seen it done, and seen it work.

Upvotes: 1

Related Questions