Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

No CLA

CLAs look good, thanks!

This introduces dependency on GOOGLETEST_VERSION which is not documented anywhere. CMake support is community-only however it would be good to understand exactly *why we are making these changes.
Please explain in greater details

This introduces dependency on GOOGLETEST_VERSION

GOOGLETEST_VERSION is a simple and straightforward CMAKE variable already used in several places.

(1) It's set in main CMakeLists.txt, see

(2) It's used in all CMakeList.txt in subdirectories:

which is not documented anywhere.

As people say on WikiTravel, No advice from Captain Obvious.

Seriously, though, this variable is not part of any API to be maintained. It is an implementation detail in the current implementation of the CMake scaffolding of the project.

CMake support is community-only
however it would be good to understand exactly *why we are making these changes.
Please explain in greater details

In order to generate the <PackageName>ConfigVersion.cmake which makes Google Test available to downstreams packages, existing CMakeLists uses CMake's built-in write_basic_package_version_file as documented on https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#generating-a-package-version-file .

Search for alternative

The fact is, in the case of a CMake <3.0, the CMakeLists.txt does not include version information in project (see snippet above). This change is the simplest one that provides the version number to write_basic_package_version_file.

I tried to include VERSION ${GOOGLETEST_VERSION} in pre-3.0 path, and CMake 2.8 rejected that option because it does not support VERSION keyword in project(). This confirms that current CMakeList.txt structure is sound.

Conclusion

I think we can confidently say the change in this PR is:

• simplest
• uses a simple and straightforward variable
• doesn't actually introduce any new dependency, because the files already depend on it
• doesn't change any public API or introduce any maintenance burden
• is very unlikely to cause any regression
• fixed the problem observed in the first place, as confirmed by two independent persons.

Thank you for the explanation.
Is there anything that would need to happen when we cut the next googletest release?
Will we have to change this variable?
Note that it is already out of sync with the actual version , which is 1.8.x ( see the branches )

Thanks

Seriously, though, this variable is not part of any API to be maintained. It is an implementation detail in the current implementation of the CMake scaffolding of the project.

In order to generate the <PackageName>ConfigVersion.cmake which makes Google Test available to downstreams packages, existing CMakeLists uses CMake's built-in write_basic_package_version_file as documented on https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#generating-a-package-version-file .

Thank you for the explanation.

Thanks for merging the PR.

Is there anything that would need to happen when we cut the next googletest release?
Will we have to change this variable?

I'm surprised by your question. I would expect any maintainer looking working towards a newer release in such a context to look at the CMakeList.txt, see that variable and increment it when applicable.

Note that it is already out of sync with the actual version , which is 1.8.x ( see the branches )

It might be or not at all, depending on project conventions.

This is master branch right after 1.8.x and the README.md announces 1.9.x.

Bumping the version number in master branch just after a release to distinguish the code from the latest release is an existing practice (see https://stackoverflow.com/a/40884130/1429390 for the first example Google search suggested just now). So, seems sane to me.

Some project adopts different practices.

Thank you for the explanation.

Thanks for merging the PR.

Is there anything that would need to happen when we cut the next googletest release?
Will we have to change this variable?

I'm surprised by your question. I would expect any maintainer looking working towards a newer release in such a context to look at the CMakeList.txt, see that variable and increment it when applicable.

Note that it is already out of sync with the actual version , which is 1.8.x ( see the branches )

It might be or not at all, depending on project conventions.

This is master branch right after 1.8.x and the README.md announces 1.9.x.

Bumping the version number in master branch just after a release to distinguish the code from the latest release is an existing practice (see https://stackoverflow.com/a/40884130/1429390 for the first example Google search suggested just now). So, seems sane to me.

Some project adopts different practices.

The reason I am asking is that we do not use CMake at all. CMake is completely community supported for googletest .
As you may see this project is supporting bazel ( main release mechanism ) , CMake, automake - community supported.

Therefore if this variable is expected ( please do be careful when making assumptions about releases, semantic versioning and such ) to play any role in the release process whatsoever there has to be something documented to this effect .

What is going to happen with the next release is that at some point we will cut the branch 1.9.x and tag it. That is it. , which would make anything based on this variable instantly wrong

(...) CMake is completely community supported for googletest . (...)

Thank you for those explanations. It makes much more sense now.

What is going to happen with the next release is that at some point we will cut the branch 1.9.x and tag it. That is it. , which would make anything based on this variable instantly wrong

Given the context, that's a totally valid point.

It is possible in CMake to automatically compute the value of the variable, based on git describe.
For example, this answer: https://stackoverflow.com/a/38836941

Is it a good idea some day to open an issue titled like "CMake variable GOOGLETEST_VERSION is fixed, not computed from non-CMake-specific information" and offer a PR? I'll also offer to add some comments on top of the CMakeLists.txt to make clear that bazel is primary build system and CMake is community supported.

Thanks for the explanation and keep up the good work! I guess you can close this issue now.

@fidergo-stephane-gourichon Thank you very much. Yes I agree that

"to open an issue titled like "CMake variable GOOGLETEST_VERSION is fixed, not computed from >>non-CMake-specific information" and offer a PR? I'll also offer to add some comments on top of the >>CMakeLists.txt to make clear that bazel is primary build system and CMake is community supported.

This would be a worthy thing to do and if you could take a look and propose a PR this would be welcomed.

In addition your idea to add some comments on top of the >>CMakeLists.txt to make clear that bazel is primary build system and CMake is community supported sounds great.. If you have some time a PR would be welcomed as well

Thanks again

Closing for now, hoping to see PRs as described, thank you again