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