[CMake] Need ideas/opinions on third party library management

[Daniel Schepler]

For what it's worth, what I've done here is to create binary packages of each third-party library for each supported platform (i.e. .deb packages for Ubuntu, .rpm packages for RHEL/CentOS, Chocolatey packages for Windows).  Except for cases where the system already provided sufficient versions of some of the libraries.  At the bottom of the internal dependency chain is a base package which sets up the infrastructure (e.g. an /etc/profile.d file to add a shell function to add entries to CMAKE_PREFIX_PATH, LD_LIBRARY_PATH, etc.) and at the top is a set of dependency metapackages, one for each product we have to build.  And yes, the middle layer has a combination of large packages like Qt and Boost with smaller packages like Expat and SQLite.

Pluses:
- Extremely convenient for an internal developer to just follow a few instructions to add our internal repository, then run "apt-get install anchorage-exata-deps".
- Similarly convenient for customers developing custom code on top of our code if we provide an archive of the required packages, then they can point apt/yum/chocolatey to a file: URL.
- It's not too difficult to support installing multiple parallel versions of the development environment for different versions of the product - just have each one install to a different location, and then the developer selects what to use by running the appropriate shell function.
- Greatly simplifies the CMake files for our code, since you just use the standard find_package() command (possibly requiring us to write a Find*.cmake module).
- Flexibility of being able to easily experiment with a new or custom-compiled version of one of the dependencies.
- If an internal developer happens to prefer working on a platform which we don't officially support (e.g. Debian testing or Mint), it's generally easy to git clone my packaging repositories and build packages for yourself.

Minuses:
- Duplicate packaging work for each different packaging tool when adding a new third-party library.
- I haven't yet automated the process of building binary packages and uploading to our repository; so when updating any package to a new version (or adding a local patch) there's a lot of manual work to do.  (dupload and reprepro help a bit for the Ubuntu builds, and nuget has a built-in facility to upload to our server; but I haven't found anything similar for the RPM builds.)
- When we do a release and then need to "fork" the repository to a new location, it requires a rebuild of all packages at least on Linux.

Overall, most of the pluses apply to everybody, whereas the minuses are just a burden on me (or a future maintainer of the repository).  So overall, it's been a big improvement over what we used to do, which was to try to maintain binary builds of the third-party libraries in SVN.
--
Daniel Schepler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160816/c9c08872/attachment.html>