[CMake] Building gtest with ExternalProject at configure time

[David Cole]

Interesting idea.

I can say for sure one of the reasons we didn't take this approach when we
first built ExternalProject was to avoid spending significant time on
ANYTHING during the CMake configure of the main project. Deferring
everything time-consuming to build time, after the configure step, was
always top of mind...

Having said that, though, the line of division between an internal project
(add_subdirectory) and external projects has always been a source of
confusion for people coming into it fresh. So a blended approach like what
you propose here could be quite useful.

I wonder if we should add an entirely separate module for such a thing...?
Perhaps called ImportedProject or something similar.

I think adding to ExternalProject for this would be the wrong approach
because it's not really "external" anymore once you start using
add_subdirectory. I'm happy to go along with the consensus, though, if
most others think differently that this.

Thanks for your work on this idea!


David C.


On Saturday, July 25, 2015, Craig Scott <audiofanatic at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150725/f45fd96c/attachment-0001.html>