[CMake] Building third party libraries along with normal targets

[Florent Castelli]

On 30/03/2017 02:10, Robert Dailey wrote:
> Interested in hearing everyone's thoughts on this idea of mine.
>
> Right now I have several third party libraries: openssl, boost,
> libpng, zlib, etc. List goes on. I need to support these libraries on
> at least 3 different platforms: ARM android, x86 linux, x86 windows.
> It's a real pain in the rear to build each of these libraries a total
> of 3 times (once per platform). It makes upgrades painful.
>
> So I was thinking: If I set up each third party library to build from
> source as a normal target with the rest of my targets, this would get
> me the libraries for each third party lib "for free". Basically, they
> would all build the same way no matter what platform I'm on. I can
> move to other platforms or architectures in the future with no extra
> effort.
This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you 
use unless you changed your mind today :)
It can be done for other projects as well. Sometimes, they even provide 
CMake build scripts you can use directly with "add_subdirectory()" so 
you don't have to write CMake scripts or use "ExternalProject_Add()" 
(which isn't all great since it doesn't propagate all your current 
project settings).

> The downside, of course, is that they build along with my normal
> targets. Which means doing "ninja clean" will clean them, when I
> really don't need to, and it will make build times get longer.
You can use ccache or its Windows variants to make it faster. But you 
also shouldn't need "ninja clean" most of the time. Possibly, you could 
just clean a specific target "ninja -t clean foo".
If you declare all your dependencies properly, then you could just 
always run "ninja" and the build will just be correct.
If your purpose is to see the compiler output again (to fix warnings), 
it is acceptable to clean and rebuild (with ccache it should be fast 
enough).
Personally, I just have a very long history in my terminal and scroll 
back or pipe the build content to a file to look at it later. Some IDEs 
will also record all the compilation output and make it available later 
(Xcode does it), then it's less of an issue.

> Any thoughts on this idea? Are there any other downsides? Is this the
> best way to have library support across platforms?

The downside is that you have to maintain lots of 3rd party build 
scripts. Depending on the side of the project, it might be a big 
overhead for the team. But it might also be totally worth it in order to 
support a lot of platforms, it just makes it easier than handling a huge 
matrix of binaries for each platform, arch and compiler and compiler 
options.

"Hey, you want to try LTO? Just add the flag and it's done!".

/Florent