Windows support

[Pwera]

Is Windows support in roadmap?

[kris-jusiak]

By windows support you mean msvc support? clang//c2 and mingw should be supported already, however, I didn't set up any testing for those yet. Moving back to your question, possibly yeah, depends on the interest in the library.

[Pwera]

MinGW doesn't have execinfo.h file, imported by ProgUtils.h.

Also here is no case for windows :)

inline auto &progname() {
#if defined(__linux__)
  static auto self = __progname_full;
#elif defined(__APPLE__)
  static char self[PROC_PIDPATHINFO_MAXSIZE] = {};
  proc_pidpath(getpid(), self, sizeof(self));
#endif
  return self;
}

[jamespharvey20]

I'd love to see MSVC support. I love what you've done with GUnit and DI. We're unfortunately cross-platform. Currently using catch & trompeloeil. Definitely incorporating DI. Will move to GUnit if it gains MSVC support. In meantime, probably either looking at gmock.py or mocks_injector (assuming it's MSVC friendly.)

[Bluesman74]

Yeah, me too. Does anyone reckon it would be possible to use the Google Test Runner for MSVC with GUnit seeing as it has Google Test as its base?

[mike-a-smith]

I'm currently using googlemock and thinking of incorporating DI, but would use GUnit to do away with defining mocks if it supported MSVC.

[jamespharvey20]

Is Visual Studio/native MSVC (not clang, c2, or mingw) support on the radar at all, or is it something we shouldn't expect to see?

[DewJunkie]

Hey, just curious, was any attempt ever made to port this over to MSVC and it was really difficult, or did not one pick it up? I'd be interested in giving it a go if you're interested in the PR, but I was curious if it proved to be overwhelmingly difficult.

[kris-jusiak]

Personally, I have never put much effort into trying to make GUnit happen with MSVC. I think there are things which might be quite easy to port but there will be some more difficult stuff as well. It's defo not zero effort to make it done but it can be done, IMHO.

[adammarks]

@DewJunkie @krzysztof-jusiak I took a look at trying to get GUnit compiled to VS2017 and ran into a brick wall with compile time string literals, the GUnit code makes use of a compile time string literal extension to GCC enabled by -Wgnu-string-literal-operator-template.

I tried some workarounds but ultimately wasn't able to get past this, but I'm not a expert in this area and it's possible that VS2019 has more support in it that would help. Also C++20 might have features in it that would help.

[kris-jusiak]

I believe that would be possible with C++20 and MSVC now by using NTTP and fixed_string. Something like the following with a bit of effort should work 🤔

• https://godbolt.org/z/e7GxMG

[DewJunkie]

Thanks, for that and the example. I've got some reading and experimenting to do with string literals. Haven't done much with that before. I'm not scared off yet, but free time is limited.
This is going to be my plan, and I figured I'd do each as a PR.

1. Setup conditionals for the compiler flags and add options for GTest/Gtest-Lite/GMock/GMake/GSteps
2. Get mocking working, that's the one I'm most interested in.
3. work on the rest.

I'm kind of a late bloomer here contributing to FOSS, but man your you tube video was really powerful. Thank you for that. Not just the testing, but also the agile flow at the end. I've shared it with my team leads and POs. It was so many concepts wrapped up very well.

[rafaelBauer]

I've been trying to compile on Windows with clang-cl since yesterday. The gherkin-cpp library uses make, and I started to create a CMake for that, but so I'm getting some linker problems with the gherkin-cpp library like:

lld-link: error: undefined symbol: __declspec(dllimport) _Compiler_new
referenced by gunit\libs\gherkin-cpp\src\compiler.cpp:13
gherkin-cpp.lib(compiler.cpp.obj):(public: __thiscall gherkin::v1::compiler::compiler(class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> const &))

In the CMake of Gherkin-cpp I have added the fmem and gherkin library as target_link_libraries. Not sure yet why it is not linking. I hope I will solve that soon.

For now the problem with the string literals, I just created an #if around it so I don't get the compiler errors, later I will try to go into that.

[rafaelBauer]

I figured to link it, but now during the test execution I am getting the following error:

[ 73%] Linking CXX executable test_Features_Calc_Steps_CalcSteps.exe
	"C:\Program Files\JetBrains\CLion 2020.2.1\bin\cmake\win\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\test_Features_Calc_Steps_CalcSteps.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x86\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x86\mt.exe --manifests  -- C:\PROGRA~2\LLVM\bin\lld-link.exe /nologo @CMakeFiles\test_Features_Calc_Steps_CalcSteps.dir\objects1.rsp @C:\Users\me\AppData\Local\Temp\nm1086.tmp
	.\test_Features_Calc_Steps_CalcSteps ENVIRONMENT SCENARIO=C:/Users/me/Documents/git/project/tests/gunit/test/Features/Calc/addition.feature:C:/Users/me/Documents/git/project/tests/gunit/test/Features/Calc/additionfile2.feature:C:/Users/me/Documents/git/project/tests/gunit/test/Features/Calc/division.feature
NMAKE : fatal error U1077: '.\test_Features_Calc_Steps_CalcSteps.EXE' : return code '0xc0000005'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX86\x86\nmake.exe"' : return code '0x2'
Stop.

I am using clang-cl 10.0.0

[DewJunkie]

@rafaelBauer I didn't deal with the gherkin-cpp changes, my thoughts were that to fix that, a PR to that project will be needed. So I just made that an option(ENABLE_GHERKIN "Enable gherkin support" OFF). I'm still going through the code, I haven't yet come to a place where I couldn't use string_view in place of the templated strings, but I'm expecting that it will crop up somewhere, and when it does, until MSVC supports the user defined string literal through a template, it will be a blocker or will require significant effort to overcome.
Are you open to having a PR that incrementally addresses the MSVC issues or all or nothing? Maybe a new branch so we don't have a few people doing the same work over again. And once we get the string literal template support, we can hopefully wrap it up. Also does it make sense to start splitting of the parts that aren't yet working as "option". Keeps master building, but not working on MSVC.

[DewJunkie]

I have some upstream PRs to gherkin-c to get it to build with msvc in windows.
Here's my plan of attack from there:

1. try to get it working with compile time value rather than type (aka string_view).
2. if 1 fails, try to get building in gcc using similar to what @krzysztof-jusiak suggested above
   a) https://godbolt.org/z/vq6Ycv This is a small change to kris' example, but make it significantly easier for me to understand.

So with either of these 2, only have to deal with gnu-literal-template issues, instead of all the others.
After that, continue work @adammarks started in his fork.

[kris-jusiak]

Sounds like a good plan to me, thank you for working on it 🙏 , let me know if you need help 👍

[qknight]

Since theese two PRs: 2f8d95a and ba1e94e we can build GUnit using CMake only. No more GNU make required to build gherkin-cpp (and its dependencies).

This means it should be much easier to get this working on windows now.

[qknight]

We are using clang-cl 11 on Windows 10 and we have very nice results already! So both targets below refer to the Windows builds:

Note: That said, expect a working PR for full Windows support of GUnit until next week! We might even get gherkin support with that!

GUnit (without gherkin)

We managed to compile and execute 'our' GUnit tests with gherkin/gherkin-cpp disabled! The tests coming with 'GUnit' are Linux/Mac specific and need slight adaptions therefore we did not execute them yet but soon to come.

We only needed to change a few lines and updated the googletest to a more recent version.

gherkin

We got gherkin-cpp compiling but the linker using clang-cl is reporting an error when building our test using gherkin internally.

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> gmockd.lib(gtest-all.cc.obj) has value MTd_StaticDebug
>>> gherkin-cpp.lib(compiler.cpp.obj) has value MDd_DynamicDebug
ninja: build stopped: subcommand failed.

[kris-jusiak]

Exciting!

[qknight]

Some update here: We've been trying to use clang-cl ~ 11 on Windows but it turns out that the GUnit relies on some very compiler specific requirements with vtable patching for GMock and this is currently not possible. However, we were able to run many GUnit tests already successfully. The issue seems that clang-cl is not using the itanium ABI.

But we'll try to change from clang-cl to a minGW based toolchain. Let's see if that works better.