2

I am currently trying to setup a project in C++, b that uses the luabind library. Unfortunately on my distro, namely Arch, this library isn't in the official repos and the one in the AUR is out of date and fails to compile.

Considering that I need the library only for this project I thought that I could make a sandboxed environment similar to python's virtualenv by building the library then installing(copying) the include files and resulting binaries in 2 sub-directories of my project called include and lib, respectively which I'll add to the linking and include paths when building. I understand why distributing the libraries with your project is bad: security and bug fixes in the meantime for example. However distributing DLLs is almost universally done on Windows(which I might do if I cross-compile) and many projects such as games on Linux tend to package their libraries to avoid inconsistencies between disrtos. Moreover if ever need a patched or forked version of a lib I doubt I'll ever find it in any official repo.

So my question is:

  • Is what I described above a common practice? Should I do it like this?
  • If not, what is the most commonly-agreed-upon solution to this problem?

NOTE: I use Cmake for build automation, if it matters

EDIT: This question slightly overlaps with mine.

Community
  • 1
  • 1
nikitautiu
  • 951
  • 1
  • 14
  • 28

1 Answers1

4

Your approach is interesting, but it is not necessary for you to devise a working system because it has already been done, and luckily, you are only one step away from the solution !

Using CMake, it is easy to automate the building and linking of external source code, using the ExternalProject module.

See http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html for useful information.

This approach has several advantages:

  • you do not have to include the library's source code in your repository
  • you can point to the specific version/git tag of the library that you know works with your software OR the latest release if you are certain it will not break compatibility
  • you do not have to write a complete CMakeLists.txt file to build a possibly complex code base
  • you can eventually configure the external project to build as a static library so you will not have to distribute shared libraries
  • you can even completely bypass this if not necessary, by trying to detect a working version of the library on your system with the usual find_package call, and only fall back to building it as an external project if not found
SirDarius
  • 41,440
  • 8
  • 86
  • 100
  • +1 cmake never ceases to be handy. However, even with the ExternalProject module, I still feel like I'm polluting my system with all the library installations. Is it ok if I set the install path(libraries and headers) to be inside the project's working directory?(for the debug build at least, the release one might link against system libraries if available or include them) – nikitautiu Nov 04 '13 at 18:39
  • 1
    Yes, that's how it is supposed to work. The installation directory should be located under CMAKE_BINARY_DIR. The whole process assumes no system-wide modification. – SirDarius Nov 04 '13 at 22:55