Windows Build Failure with Gtest

[ahnaf-tahmid-chowdhury]

Issue Description:

Overview:
I and @gonuke have encountered a persistent build failure on the Windows platform in our workflow file (#860, #869). Despite updating Gtest to version 1.13.0 and re-running the workflows, the problem persists. Interestingly, the Linux and Mac workflows have been successful with the latest Gtest version.

Affected Workflow:

• Windows Build - Workflow Link

Expected Behavior:
The Windows build should successfully pass, just like the Linux and Mac builds, after updating Gtest to v1.13.0.

Observed Behavior:
The Windows build is failing consistently, indicating there might be an issue specific to the Windows environment.

Error Message:
The error message encountered during the Windows builds can be found in the workflow log linked above.

Related Logs:

• Linux Build Log: Workflow Link
• Mac Build Log: Workflow Link

We would appreciate any assistance or insights from the community to identify and resolve this issue so that the Windows build can proceed successfully with Gtest v1.13.0. Thank you for your support!

Tagging: @makeclean (who mentioned the Gtest-related issue).

[gonuke]

Are you testing locally on Windows, or only via our GitHub actions workflows?

My best guess is that something has changed with the GitHub build environment and not the code itself.

[ahnaf-tahmid-chowdhury]

I haven't tested it on my local Windows. The tests were conducted only through our GitHub actions workflows.

Yes, I am also guessing the same thing. I have found a conflicting definitions of the same class which located in two different files.

D:\a\DAGMC\DAGMC\src\gtest\gtest-1.13.0\include\gtest/gtest-assertion-result.h
C:\Miniconda\Library\include\gtest/gtest.h

[gonuke]

The gtest.h headers are installed as part of the yaml-cpp conda package that is present by default. I don't think we need this package, or any of the things that depend upon it, so I am trying to build after removing that package. stay tuned

[gonuke]

More information: The Windows build currently installed yaml-cpp v0.7.0 by default. It is not clear when that changed from the previous version or why:

• the 0.7.0 package was pushed to the Anaconda channel 14 months ago and the conda-forge channel 10 months ago
• it minicoda setup action we are using may or may not have changed which version they were including more recently (I'm not currently interested in investigating that further at this time)

Notably, the previous version (v0.6.3) used gtest v1.8.0 which is the same as we use. The current version of yaml-cpp uses gtest v1.11.0.

Long term solutions include some combination of:

• removing the yaml-cpp package during testing
• discussing with yaml-cpp maintainers about the utility of including gtest in their package
• tweaking CMake to put our own header path head of the system header paths - there are differing opinions on the robustness of this strategy

[ahnaf-tahmid-chowdhury]

The gtest.h headers are installed as part of the yaml-cpp conda package that is present by default. I don't think we need this package, or any of the things that depend upon it, so I am trying to build after removing that package. stay tuned

Amazing!!! It worked!!! I tried various methods, but it turns out that yaml-cpp was the culprit causing the issue. Removing that package made all the difference. Thank you so much for your help. Cheers! 🎉

[gonuke]

I've raised an issue on the yaml-cpp conda-forge feedstock project - we'll see what opinions they have.

[ahnaf-tahmid-chowdhury]

I believe the most robust approach is to remove the yaml-cpp package during testing. This way, we can consistently use our exact version of gtest every time. However, I attempted to prioritize our own header path ahead of the system header paths by modifying the CMake configuration, but unfortunately, it didn't yield the desired results.

I tried the following method:

# Add the include directories for Google Test to the gtest target
target_include_directories(gtest PRIVATE ${GTEST_DIR})
target_include_directories(gtest PRIVATE ${GTEST_DIR}/include)

Despite these changes, the custom header path didn't take precedence as expected.
Maybe there are some other ways available.