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

[Elizabeth A. Fischer]

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.lists at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160812/0d7529d9/attachment.html>