[CMake] Building third party libraries along with normal targets

[Florent Castelli]

On 30/03/2017 03:54, Robert Dailey wrote:
> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
> <florent.castelli at gmail.com> wrote:
>> 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 :)
> You mean this?
> https://github.com/Orphis/boost-cmake
>
> It's on the drawing board, for sure. It's the best solution I've
> found. It's also part of the reason I'm asking this question to begin
> with.
>
> Although, this specific method of building boost doesn't use
> superbuild, it uses normal add_subdirectory() with target.
It doesn't "super build" its dependencies, you have to provide them 
externally, but it is a possible addition.
But it is designed to be part of a super build environment and is used 
as such at some large companies shipping to millions of people.

>
>> 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).
> Long term, I'm thinking a project like hunter[1] would be the best
> choice. The problem with hunter is that it doesn't separate concerns
> between host machine and target host. Specifically, when cross
> compiling.
>
> All the superbuild commands assume linux command syntax, simply
> because I specified a toolchain utilizing android NDK. For this reason
> it requires a lot of TLC to get working.
>
> [1]: https://github.com/ruslo/hunter
There are those issues and also ABI changing flags that can become an 
issue as they aren't always propagated from what I can see.

>> 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.
> Never used ccache before, what does it do? Also if even if you ninja
> -t to clean, it will also clean dependencies. So if I specify those
> in-project dependencies that actually build third party libs, those
> will be cleaned too.

It's a program you use to record compilation outputs and save them to a 
disk cache. If you build a file again, instead of compiling it, it will 
just fetch the outputs from the cache and return the same warnings. It's 
usually a safe optimization in a build pipeline and is quite easy to use 
with CMake and Ninja generator.

It works well with GCC or Clang and there are some alternative versions 
for the Microsoft compiler too.

/Florent