[CMake] Building gtest with ExternalProject at configure time

[Ruslan Baratov]

On 25-Jul-15 10:20, Craig Scott wrote:
> Hi all. I was surprised recently to find little in the way of a simple 
> method to build gtest as part of a CMake project without having to 
> either (a) add the gtest source to my own project or (b) use 
> ExternalProject and then have to manually create import libraries for 
> tests to link against. Since neither option was particularly 
> appealing, I found a way to combine the best of both approaches 
> without the downsides subsequently wrote a blog article showing how to 
> do it. The general gist of it is to use ExternalProject to download at 
> configure time and then add the gtest source to your project using 
> add_subdirectory(). This means gtest builds with the same compiler and 
> settings as the rest of your project, but it does not require adding 
> the gtest source to your project tree. The gtest and gtest_main CMake 
> targets are automatically available in your project without having to 
> define any import libraries manually.
>
> The method I used was relatively straightforward, I create a 
> sub-project in the main project's build area and build it as part of 
> the main CMake step. All the sub-project does is use ExternalProject 
> to download the gtest source to a defined location, so the main 
> project then has the source already in place and can therefore use 
> add_subdirectory() to bring gtest into your main project. It turns out 
> that it was also easy to make the approach generic so it could be 
> applied to any external CMake-based project. The blog article with all 
> the details can be found here:
>
> http://crascit.com/2015/07/25/cmake-gtest/
>
> What struck me after investigating and implementing this was how 
> useful it might be if ExternalProject had an option which made it run 
> (at least some steps) at configure time (i.e. when CMake is run) 
> rather than at build time. My approach seems to suggest it may not be 
> all that hard, but the ExternalProject implementation is more involved 
> than I wanted to pick apart. If anyone wants to explore it, my blog 
> article probably shows you enough of a clue to how it might be 
> possible to do it.
>
> -- 
> Craig Scott
> Melbourne, Australia
> http://crascit.com
>
>
Hi,

I've leaved a small comment in your blog but don't see it :) So I reply 
here.

In short find_package is much more convenient option than 
add_subdirectory so it's still better to run install (I know that this 
particular GTest project doesn't have install by default). Also there 
are a lot of other stuff you need to solve to generalize this approach. 
For instance version of GTest saved in gtest-CMakeLists.txt of local 
project, assume: A use GTest 1.0, B use GTest 2.0, C use A and B - what 
version of GTest we should use? If you're interested here is a package 
manager I'm working on: https://github.com/ruslo/hunter. GTest package: 
https://github.com/ruslo/hunter/wiki/pkg.gtest

Cheers, Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150725/cfad0fc0/attachment.html>