Wow I actually completely forgot about that lol. I think I was looking into it for some other reasons, not related to work. I will have to look into it again. I don't really remember much about it.
Thanks for the reminder. On Sat, Aug 13, 2016 at 7:02 PM, Ruslan Baratov <ruslan_bara...@yahoo.com> wrote: > Hi, Robert > > According to your GitHub account you've send a trivial patch about a year > ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I > wonder what is your experience, have you tried it? Have you run into some > troubles? > > Thanks, Ruslo > > > On 12-Aug-16 22:59, Robert Dailey 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