A superbuild will work, and you can write your own Find*.cmake so that find_package works - you don't need most of what the real Find_package would do for you because you already know what is installed where as you control that. But, can you live with the trade off: long build times?
What my company did to solve a similar problem is write a tool (this took most of a year for a couple people, a lot that is very specific to our environment so sharing doesn't make sense) that that will install packages in a docker (linux only) image. Each project we build has a "pin file" that lists the packages that project depends on. When we upgrade boost, the build creates a .rpm package which the tool automatically installs for the build to use. What really makes our approach work is the integration into our CI system, when I change boost I verify the build in just one architecture, then push. The CI system takes over to build every supported architecture, and then it deploys the packages - I don't have to build them all by hand (of course if something fails I need to figure that one out). Then I just have to pin the new package and our build system takes care of ensuring the new version is in place. As I said, the above is complex and very custom to our environment. I'm not entirely happy with it, but I can't come up with anything better for our requirements. In particular I can go backward to any released version of code and rebuild it - meaning we can fix bugs in old versions easily if a customer isn't willing to upgrade. -----Original Message----- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey Sent: Friday, August 12, 2016 3:00 PM To: CMake <cmake@cmake.org>; CMake Developers <cmake-develop...@cmake.org> Subject: [CMake] Need ideas/opinions on third party library management Hello, There is an internal C++ product at the company I work for which I have written a series of CMake scripts for. This project actually has dependencies on several open source libraries, such as boost, freetype, openssl, etc. Right now what we do is build each of these third party libraries *by hand*, once for every platform we support (Windows, Linux x86, Android NDK). Then we stuff the includes (headers) and libraries (static/shared) in a submodule and the primary code base's CMake scripts pull them in as interface targets. This works well and is light-weight but is a pain when upgrading or changing libraries. It's a pain because if I want to upgrade boost, I have to build it up to 6 times (once for each platform and once for each configuration). I've been thinking of a different approach for a while. I've done some toying around with the "Super Build" concept, where I have a separate CMake project that does nothing but use the ExternalProject module to build libraries in real time along with our project. So the order of operations would be as follows (for our automated build server): 1. Clone our "Third Party" repository 2. Use CMake to generate & build the "Super Build" project (this builds boost, openssl, freetype, etc for the current platform). 3. Clone the main code base's repository 4. Use CMake to generate & build, using find_package() to refer to interface targets exported by those third party libraries built in step 2 Obviously this will make builds take significantly longer, because we're constantly rebuilding the same third party libraries over and over again. However, it virtually eliminates the maintenance burden for third party libraries because they are built inherently with everything else. Note that I can't refer to pre-built libraries in our build environments because we need very specific control over the versions of our libraries as well as the toolchains that were used to build them. Also we may specifically build our libraries a certain way (such as boost). For this reason we do not rely on our external environment or external package managers to fulfill third party dependencies, like most open source projects do on Linux for example. Does this "Super Build" approach sound like a better idea? What other options are available? The downside with the "Super Build" solution is that it will become very difficult to make the transition between building third party and building our code base seamless. I can't do both in the same generate step because find_package() can't be called until the libraries are built & installed. -- 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 -- 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
