[CMake] Need ideas/opinions on third party library management

[Ruslan Baratov]

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.