← All tasks
cppjbeder/yaml-cpp #488Not a task: already works

Embedding of gtest/gmock in source tree

envgap__jbeder__yaml-cpp-488

01 / FAILURE SIGNATURE

As reported upstream

No identifying execution failure has been captured.
Not a benchmark task.
  • The project already builds and runs before the fix, so there is nothing to repair.

02 / ENVIRONMENT RECIPE

Base commit
1b50109f7bea60bd382d8ea7befce3d2bd67da5f
Manifest
test/CMakeLists.txt
Reproduce
Awaiting issue-specific recipe
Run under trace
Awaiting a meaningful runtime command

03 / ORIGINAL ISSUE TEXT

jbeder/yaml-cpp #488 · read the original issue
The current approach used by yaml-cpp is to embed gtest/gmock in `test/gmock-1.7.0`.  While this works fine for the most part, it doesn't work well when you're integrating it into a larger build which also includes its own gtest, e.g. a later version such as 1.8.0.  It would be nice if this could be made optional.  The headers and libraries can conflict.



As a suggestion, this is the approach I took in a different project: [GTest.cmake](https://github.com/ome/ome-files-cpp/blob/v0.2.0/cmake/GTest.cmake).  Here, we pass in a variable `GTEST_SOURCE` which points to the location of the sources.  If unset, we simply use `find_package` and use an external version.  If set, we use the internal version (or the version pointed to outside the source tree).  An option could be added to yaml-cpp to do an equivalent action, e.g. `build-gtest` or `build-gmock`.  It could even be defaulted based upon the result of `find_package`.



Also worth noting: gtest 1.8 combines gmock and no longer enforces the requirement to "vendor" into a source tree.  It's now locally installable again, with the proviso that it needs building with a compatible set of compiler options (so no different than most other libraries!).





Regards,

Roger
Continue on GitHub ↗

04 / LABELS

Labels from the report text only; not yet run

No supported category has been assigned.

Label rules and the text that matched
[]