views:

17

answers:

2

Hello,

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.

Thanks a lot

Greg

+1  A: 

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.

mjfgates
Thanks for the reminder on the repository growing big with frequent library updates.
fraktal
+1  A: 

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.

honk
Thanks, you point out to a number of Linux-specific issues that I wasn't aware of, being more a Windows guy.
fraktal
One thing I forgot to mention: this is not an open-source project. So the only developers working on it is our team of 3. But your point about shared libraries being favored on Linux really is something that we need to keep in mind.
fraktal