Closed meekee7 closed 4 years ago
I fixed the CMake URL and did the tab conversion.
Specifying the gtest branch is more complicated than it sounds.
I pinned the external to the tag release-1.10.0 (commit #703bd9c). That was done by checking out that commit within the external and then committing the directory of the external in the main repo. (The external directory is like a special file for Git). This was part of my commit #46fac32. You can verify that it works by opening my branch on GitHub: the external is resolved correctly and GitHub links directly to that gtest commit I used.
The gtest repo has a branch v1.10.x we could use. It is already slightly ahead of that release tag. It could also be deleted in the distant future. I am not convinced that tracking volatile branches of a foreign repo which you do not control is a good idea.
Key options are:
In my opinion, the third option would be the best.
The 3rd option does sound like a safe bet indeed, as not specifying a submodule branch has proven to cause some issues when trying to update a submodule.
I've forked the GTest repo and it can now be found here: https://github.com/OpenTrespasser/googletest
You can now update the URL in .gitmodules.
I updated .gitmodules
: the branch is specified and the URL is that of our new gtest fork.
The submodule itself now points to the head of the v1.10.x branch.
The Google Test (aka GTest) library is added as a Git submodule, using version 1.10.0. https://github.com/google/googletest Google Test is a unit test framework for C++, widely used in the industry. It is portable across compilers and operating systems. For our convenience, it comes with CMake project definitions which we can use directly. Having a unit test framework - and writing unit tests - would make it easier to observe the effects of code changes and verify their correctness.
The StdTest project is introduced as an example unit test project. It contains a few tests for the changes from PR #49.