This is what Spack and other meta builders do. See http://github. com/llnl/spack On Aug 12, 2016 3:59 PM, "Robert Dailey" <rcdailey.li...@gmail.com> wrote:
> 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
