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
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]