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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
