As Felix (Github User fberlakovich) told me it can cause problems to use gtest not compiled with exactly the same compiler flags. Most distros supply already compiled versions of gtest that might be compiled differently.

We could support both variants: if the user wants to use the installed version it will be used and otherwise the embedded copy will be used. What do you think?

I think pino suggests a way to use installed gtest sources and not the compiled library. Many distros (e.g. debian) ship with the gtest sources. If this works reliably it is definitely preferrable to shipping with the gtest sources. However, this elimantes the option to build the tests out of the box (without user interaction).

From what I saw, the flag is GOOGLETEST_ROOT and not GTEST_ROOT. FYI: under debian wheezy it is sufficient to install libgtest-dev and call cmake with cmake -DGOOGLETEST_ROOT=/usr/src/gtest

I think pino suggests a way to use installed gtest sources and not the compiled library.

Exactly.

However, this elimantes the option to build the tests out of the box (without user interaction).

And eliminates also the embedded copy of some 3rd party source, which is usually a Bad Thing (tm).

From what I saw, the flag is GOOGLETEST_ROOT and not GTEST_ROOT.

GOOGLETEST_ROOT is the internal cmake cache variable holding the path, while GTEST_ROOT is the user variable which can be passed to cmake. Users shouldn't know what GOOGLETEST_ROOT is about, it's an internal implementation detail to have a different cache variable not clashing with the one used by users to pass the gtest source root.

I full agree that it is a bad thing to deliever foreign source, but I could not find gtest as source in neither Arch Linux nor Fedora. If most of the major distros do it the debian way (have a package for gtest-source), I am the first to remove our embedded copy. But even Debian Wheezy seems not to have it.

@fberlakovich can you re-check which distros have it.

@pinotree what do you think about updating our CMake to use installed gtest-source if requested by CMake Variable?

Btw. the ongoing decision process is documented here.

But even Debian Wheezy seems not to have it.

In Debian it is called libgtest-dev, installing the sources to /usr/src/gtest.

@pinotree what do you think about updating our CMake to use installed gtest-source if requested by CMake Variable?

Isn't that what this merge request already does, e.g. passing -DGTEST_ROOT=/usr/src/gtest on a Debian system?

Note also this is about using some external gtest -- it does not imply it must be packaged somewhere by your distro (if any), but simply that the gtest sources are outside the elektra sources.

Thanks for your effort, most of it was taken for dae461e

Internal variant of gtest was stripped down, but it will stay for some time because nearly all systems, except of debian, do not provide an easy way to install gtest sources.

Internal variant of gtest was stripped down, but it will stay for some time because nearly all systems, except of debian, do not provide an easy way to install gtest sources.

This will surely not give an incentive to those distros to provide the gtest sources (as also upstream currently recommends, until they change again their mind...). Also, not all the distros even compile or run the upstream tests during the build, and gtest surely is not needed for building elektra.

Further, for developers GTEST_ROOT could be set to the root of sources as checked out from the googletest SVN, so it's just a matter of svn co ... / svn up.

My advice is still to get rid of any embedded 3rd party source code copy, which always adds an additional maintaneance burden.

This will surely not give an incentive to those distros to provide the gtest sources (as also upstream currently recommends, until they change again their mind...). Also, not all the distros even compile or run the upstream tests during the build, and gtest surely is not needed for building elektra.

No, it is not needed for building it, but the idea is that it will become more important for testing it. I personally find the incentive for testing the software (make it as easy as possible), more important than giving incentives for doing proper software distribution.

Further, for developers GTEST_ROOT could be set to the root of sources as checked out from the googletest SVN, so it's just a matter of svn co ... / svn up.

I am fully aware for that. This is good for developers (and thus your suggestion is supported as is: so one can set GTEST_ROOT and the code from there will be preferred).

It cannot be used for automatical building with packages only, but instead it needs one manual step or one step to download 3rd party sofware. And I really do not want to split testcases that will always run (not depending on gtest) and those that need gtest and might not run if the user does not do the svn up and setting GTEST_ROOT.

My advice is still to get rid of any embedded 3rd party source code copy, which always adds an additional maintaneance burden.

You are right and I fully agree that it is not perfect. But for our project it is more important that users easily can run all testcases without any manual step than it is to evangelize proper software distribution. Elektra currently is too small for such a thing anyway :-)