cmake project with google test

[dmott]

I have a remote cmake project that configures, compiles and runs fine. I can run the produced test binaries with ‘make test’. However, when enabled integration: ‘The project contains unit tests based on: GoogleTest’ cmake wont get past the configure stage with the following errors:

The C compiler identification is GNU 6.4.0
The CXX compiler identification is GNU 6.4.0
Check for working C compiler: /usr/local/bin/cc
Check for working C compiler: /usr/local/bin/cc — works
Detecting C compiler ABI info
Detecting C compiler ABI info – done
Detecting C compile features
Detecting C compile features – done
Check for working CXX compiler: /usr/local/bin/c++
Check for working CXX compiler: /usr/local/bin/c++ — works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info – done
Detecting CXX compile features
Detecting CXX compile features – done
Found XercesC: /usr/lib64/libxerces-c.so (found version “2.8.0”)
Looking for pthread.h
Looking for pthread.h – found
Looking for pthread_create
Looking for pthread_create – not found
Looking for pthread_create in pthreads
Looking for pthread_create in pthreads – not found
Looking for pthread_create in pthread
Looking for pthread_create in pthread – found
Found Threads: TRUE
Found TBB: /opt/intel/tbb/include (found version “2018.0”) found components: tbb tbbmalloc
Found Protobuf: /usr/local/lib/libprotobuf.so;-lpthread (found version “3.5.1”)
Found GTest: /usr/local/lib/libgtest.so
Found Protobuf: /usr/local/lib/libprotobuf.so;-lpthread;-lpthread (found version “3.5.1”)
Found OpenSSL: /usr/lib64/libcrypto.so (found version “0.9.8j”)
Found CURL: /usr/lib64/libcurl.so (found version “7.19.7”)
Found LibXml2: /usr/lib64/libxml2.so (found version “2.7.6”)
Found ZLIB: /usr/lib64/libz.so (found version “1.2.7”)
CMake Error at TestFramework.cmake:8 (target_link_libraries):
Cannot specify link libraries for target “pthread” which is not built by
this project.
Call Stack (most recent call first):
CMakeLists.txt:221 (include)

Configuring incomplete, errors occurred!
See also “xxx/.build/CMakeFiles/CMakeOutput.log”.
See also “xxx/.build/CMakeFiles/CMakeError.log”.
Exception reported by CMake server: Configuration failed.
Uploading sources to the build machine to initialize CMake Server…
VisualGDB: Found 3510 source files to transfer. Checking the source cache to find modified files…
VisualGDB: No file changes detected. If you believe it’s a mistake, please clean the project and build it again.
VisualGDB: No file changes detected. If you believe it’s a mistake, please clean the project and build it again.
Found Protobuf: /usr/local/lib/libprotobuf.so;-lpthread (found version “3.5.1”)
Found Protobuf: /usr/local/lib/libprotobuf.so;-lpthread;-lpthread (found version “3.5.1”)
CMake Error at TestFramework.cmake:8 (target_link_libraries):
Cannot specify link libraries for target “pthread” which is not built by
this project.
Call Stack (most recent call first):
CMakeLists.txt:221 (include)

Configuring incomplete, errors occurred!
See also “xxx/.build/CMakeFiles/CMakeOutput.log”.
See also “xxx/.build/CMakeFiles/CMakeError.log”.
Exception reported by CMake server: Configuration failed.
wh1+x: Exception reported by CMake server: Configuration failed.
at wh1.c2[_InType,_OutType](_InType a)
at g61.x(String[] a)
at g61.l_2(Hello a)
at wh1.m1()

Please advise

[support]

Hi,

Sorry, unit tests for Advanced CMake projects are not officially supported yet, so bugs like this one are to be expected. Either way, we can help you resolve this if you could attach the generated TestFramework.cmake file. Most likely CMake gets confused with some library references.

[dmott]

TestFramework.cmake:

#...comments...

include_directories(TestFramework/include TestFramework TestFramework/Platforms)
add_definitions()
target_link_libraries(pthread)

 

 

[support]

Hi,

Looks like the TestFramework.cmake file got generated incorrectly (test frameworks are not fully supported for advanced CMake projects). Please try adjusting it to target_link_libraries(<target name> pthread).

[dmott]

Interesting. Now after the successful build a popup says ‘Your version of VisualGDB does not support linux’ Its a large project with a lot of targets, which project types support integrated gtest?

 

[dmott]

I went through the walk-through here: https://visualgdb.com/tutorials/tests/googletest/. The sample project compiles but the tests dont appear in the test explorer window.

Please advise

 

[support]

Hi,

No problem, we can help you troubleshoot this, however it looks like your VisualGDB technical support period has expired (your VisualKernel support is still actiev). In order to keep receiving technical support, please renew your license here: https://sysprogs.com/splm/mykey

[dmott]

all set, what should I look at?

[support]

Hi,

Thanks for renewing your support. We have investigated the problem and it looks like the VisualKernel 3.0 Beta is interfering with the VisualGDB test discovery functionality. We have located and fixed the problem. Please try this VisualKernel build, it should no longer cause conflicts with VisualGDB: http://sysprogs.com/files/tmp/VisualKernel-3.0.1.2143.msi

[dmott]

I was able to run one test today but as it happens I performed a bit of work on our build system today and it’s stopped working. All the test build targets show up in the solution explorer, everything compiles and executing ‘make test’ runs the gtest binaries.

At the end of the build I see this in the output panel:

VisualGDB: Warning: _ZN7testing8internal12UnitTestImpl11RunAllTestsEv not found in the output file. Please ensure that your test framework is initialized properly.

The Tests panel shows this:

[2/16/2018 5:10:48 PM Informational] —— Discover test started ——
[2/16/2018 5:10:49 PM Informational] Loading …xxx.vgdbtestcontainer…
[2/16/2018 5:10:49 PM Informational] Downloading ….xxx_tests to discover tests…

[2/16/2018 5:10:51 PM Informational] Test container loaded (lookup: 2 msec, fetch: 932 msec, symbol list: 49 msec)

[2/16/2018 5:10:51 PM Error] Value cannot be null.
Parameter name: filePath
[2/16/2018 5:10:51 PM Informational] ========== Discover test finished: 3 found (0:00:02.2780564) ==========

 

It also seems to drop and reconnect the ssh session.

 

Please advise

[support]

Hi,

This looks like CMake doesn’t report some of the target information to VisualGDB. This is to be expected, as unit tests projects are not officially supported for Advanced CMake yet. That said, we might be able to investigate/fix this if you could create a basic repro project and send it to us (or attach it here).

[dmott]

Here’s a project with a similar symptom.  This one is showing one of the tests in the test explorer but another isn’t discovered.

[support]

Hi,

It looks like your are using an external build of GoogleTest. VisualGDB can only recognize unit tests if they are built with a patched version of GoogleTest that contains VisualGDB-specific code. Please try creating a regular MSBuild-based test project, locate the files automatically added by VisualGDB and ensure you add the same files to your CMake-based project. This should get VisualGDB to recognize the tests as if it was a normal project created through the wizard.

[dmott]

Thanks, I updated the example here. This is also what I’m seeing in the production build. The test discovery phase seems to only scan the first GTest binary though multiple are being created.

Please advise

[support]

Hi,

Thanks, we have rechecked the updated example. VisualGDB currently only supports one test binary per project (we might be able to improve it in v5.4), sorry. As a workaround please try defining tests in static libraries and linking them into one large executable.

We also tried actually running tests in your project, however they did not report the results as the SysprogsTestHook_TestStartingEx() function was never called. This could be caused by differences between the test framework you are using and the one VisualGDB puts into newly created projects. Please try creating a regular MSBuild-based test project, setting a breakpoint in SysprogsTestHook_TestStartingEx(), reviewing the call stack and analyzing why it doesn’t get called in your project.

Naturally once we officially support advanced CMake-based unit tests, we will ensure it works out-of-the-box.

[Author]

Posts