[dabramson]

I did a bit more digging and found this output in the VGDB diagnostics window when I ‘debug’ the tests in test explorer.

SSH [99]: executing command: "/opt/psi/BKMainApp/TestSharedObj_HelloWorldVgdbMsBuild2" --gtest_list_tests
SSH [99]: command exited with code 0 after 50 msec
TestSharedObj_HelloWorldVgdbMsBuild2 => 6 output lines
Discovered 3 tests using the advanced discoverer
SSH [100]: executing command: "mkfifo" "/tmp/01d673d5-eb13-41d1-999a-8c7eda47ea45"
SSH [100]: command exited with code 127 after 94 msec
Unexpected exception: Failed to create a temporary pipe for reading the test reports
------------------ System.Exception ------------------
System.Exception: Failed to create a temporary pipe for reading the test reports
at pe.b1()
at t91.m(k52 a)
at s52.y()
at yv.x_2()
at VisualGDB.GDBDebugEngine.q1(ba1 b, s1 a)
Unexpected exception: Failed to create a temporary pipe for reading the test reports
------------------ System.Exception ------------------
System.Exception: Failed to create a temporary pipe for reading the test reports
at pe.b1()
at t91.m(k52 a)
at s52.y()
at yv.x_2()
at VisualGDB.GDBDebugEngine.q1(ba1 b, s1 a)
SSH [101]: executing command: "rm" '/tmp/01d673d5-eb13-41d1-999a-8c7eda47ea45'
SSH [101]: command exited with code 1 after 49 msec

I’m guessing the that mkfifo not being present on the target is an issue. Can you confirm?

Also, can you tell me any other commands that running unit tests from test explorer will rely on? I’d like to try and get them added in one group if there are more as our guy that manages busybox for the target is only part-time.

Thanks,

Dave

• This reply was modified 5 years, 3 months ago by dabramson. Reason: additional related information requested

[dabramson]

Thank you! The tests now build.

I’m having trouble getting them to run with the VS test explorer, but I’ll start a new post for that.

[dabramson]

I made a new project in a totally new solution. I found the following 2 cases. The first case is expected behavior. The incorrect path issue is introduced by correcting the build failure in the first case.

The short story is that it seems the test project would build without issue if it didn’t need symbols from another project. Adding a reference to the project containing the code under test causes the paths to the test framework to be messed up in the msbuild.mak file.

 

—————————————————————————————-
CASE 1 ———————————————————————————

When the shared object project is NOT referenced by the test project the msbuild.mak for the test project has to correct paths to the test framework. The test framework source compiles, but the class in the shared object cannot be referenced by the test project. The build fails with an ‘undefined reference to `BasicCounter::BasicCounter()’ error for every use of the class in the test (as would be expected).

-include VisualGDB/Debug/gtest-death-test.dep
VisualGDB/Debug/gtest-death-test.o: TestFramework/src/gtest-death-test.cc VisualGDB/Debug/gtest-death-test.gcc.rsp
@echo gtest-death-test.cc
$(_V)/home/psidev/opt/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ @VisualGDB/Debug/gtest-death-test.gcc.rsp -c "TestFramework/src/gtest-death-test.cc" -o "VisualGDB/Debug/gtest-death-test.o" -MD -MP -MF "VisualGDB/Debug/gtest-death-test.dep"

—————————————————————————————-
CASE 2 ———————————————————————————

After referencing the shared object project in the test project via the standard VS add reference feature the msbuild.mak file for the test project does not have the correct paths to the test framework and the build fails because it cannot compile the test framework.

-include VisualGDB/Debug/gtest-death-test.dep
VisualGDB/Debug/gtest-death-test.o: gtest-death-test.cc VisualGDB/Debug/gtest-death-test.gcc.rsp
@echo gtest-death-test.cc
$(_V)/home/psidev/opt/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ @VisualGDB/Debug/gtest-death-test.gcc.rsp -c "gtest-death-test.cc" -o "VisualGDB/Debug/gtest-death-test.o" -MD -MP -MF "VisualGDB/Debug/gtest-death-test.dep"

• This reply was modified 5 years, 3 months ago by dabramson.

[dabramson]

I’m on version 5.4 build 2737, which is what installed when I downloaded from the site earlier today. Is that the latest version?

In the msbuild.mak file I found that adding the path to the gtest source will let make find the gtest source file. A snippet from the modified mak file is below. With this snippet in place the gtest-deat-test.cc file compiles, but the gtest-filepath.cc get the “No rule to make target error”.

-include VisualGDB/Debug/gtest-death-test.dep
VisualGDB/Debug/gtest-death-test.o: TestFramework/src/gtest-death-test.cc VisualGDB/Debug/gtest-death-test.gcc.rsp
@echo gtest-death-test.cc
$(_V)/home/psidev/opt/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ @VisualGDB/Debug/gtest-death-test.gcc.rsp -c "TestFramework/src/gtest-death-test.cc" -o "VisualGDB/Debug/gtest-death-test.o" -MD -MP -MF "VisualGDB/Debug/gtest-death-test.dep"

-include VisualGDB/Debug/gtest-filepath.dep
VisualGDB/Debug/gtest-filepath.o: gtest-filepath.cc VisualGDB/Debug/gtest-filepath.gcc.rsp
@echo gtest-filepath.cc
$(_V)/home/psidev/opt/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ @VisualGDB/Debug/gtest-filepath.gcc.rsp -c "gtest-filepath.cc" -o "VisualGDB/Debug/gtest-filepath.o" -MD -MP -MF "VisualGDB/Debug/gtest-filepath.dep"

Seems that something is wrong with the msbuild mak file generation.

• This reply was modified 5 years, 3 months ago by support. Reason: formatting

[dabramson]

You guys rock!

It works for me.

Will this build and build 2346 be rolled into the general product updates? I wouldn’t want to update the tool and then loose the functionality you guys but in those builds.

Thanks,

Dave

[dabramson]

Hello,

Thanks for the build, and great work! I’m now reporting test result from my embedded STM32 project.

Thanks,

Dave

[dabramson]

Hi,

So I have upgraded the ST-Link firmware and only seen this error once since then. I’ve also tried it on a different PC and did not have the issue there. The two PCs have different windows versions (7 on the one with the error, 10 on the other), and also different STM driver versions.

I’m thinking there is something funny going on with versioning, so I’m going to make sure all of the STM software is at the latest versions on all PCs. If I still see the issue once I have less variables to deal with I’ll report back here.

Thanks,
Dave

[dabramson]

Hi,

Yes, I am looking to exclude tests when running from the command line (on a build server) with the /runtests option. I’d love it if you added that option!

Thanks,

Dave

[dabramson]

Ok.

It’s unfortunate that there is only a manual work around. This also means that shared settings do not work on the TFS build server. I had to manually install the compiler instead of it being synced automatically when I queued the build.

[dabramson]

Any word on this feature?

[dabramson]

Hello,

Yes, that would would work quite well!

Thanks for the responsiveness.

Dave

[dabramson]

Hello,

Yes, I’m using /runtests in a command line build step to execute the tests, and I have the XML output. I don’t expect that they would be automatically exported to TFS. But I think the output format should be compatible with one of the formats that the “Publish Test Results” build step understands. https://docs.microsoft.com/en-us/vsts/pipelines/tasks/test/publish-test-results?view=vsts. Better still, a command line parameter to select the test result output schema (the current proprietary one or JUnit for example).

Are there plans to support the standard unit test result formats?

If there are plans do you have a rough timeline?

That would help me decide if I want to put the time into a custom test results converter, as you suggest above.

 

Thanks,

Dave

[dabramson]

Thanks!

That was the clue I needed. I stopped and started the agent (the process), and now the solution builds successfully. I knew that you had to restart Visual Studio to get it to load new environment variables, but I’m pretty new to using build agents so didn’t realize the same rule applied with them. Makes sense though…

 

Regards,

Dave

[dabramson]

Hello,

The build agent was running as a network service. I changed it to running under a domain account and things seem to be going much better. It looks like the team sharing is syncing in the MSBuild step, and the toolchain is found.

Thanks,

Dave

 

[dabramson]

I have just installed VisualGDB 5.4 Preview 3, build 2193. The issue seems to have disappeared.

[Author]

Posts