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
--
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
