You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.)
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.
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.
@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.
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 🤔
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.
Setup conditionals for the compiler flags and add options for GTest/Gtest-Lite/GMock/GMake/GSteps
Get mocking working, that's the one I'm most interested in.
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.
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 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.
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:
try to get it working with compile time value rather than type (aka string_view).
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.
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.
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.
Activity
kris-jusiak commentedon Jul 1, 2017
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 commentedon Sep 8, 2017
MinGW doesn't have
execinfo.hfile, imported byProgUtils.h.Also here is no case for windows :)
jamespharvey20 commentedon Oct 9, 2017
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 commentedon Oct 12, 2017
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 commentedon Nov 10, 2017
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 commentedon May 3, 2018
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 commentedon Aug 22, 2020
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 commentedon Aug 24, 2020
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 commentedon Aug 24, 2020
@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 commentedon Aug 24, 2020
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 🤔
DewJunkie commentedon Aug 30, 2020
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.
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 commentedon Sep 21, 2020
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:
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 commentedon Sep 21, 2020
I figured to link it, but now during the test execution I am getting the following error:
I am using clang-cl 10.0.0
DewJunkie commentedon Sep 25, 2020
@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 commentedon Sep 30, 2020
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:
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 commentedon Sep 30, 2020
Sounds like a good plan to me, thank you for working on it 🙏 , let me know if you need help 👍
qknight commentedon Feb 16, 2022
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 commentedon Mar 1, 2022
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.
kris-jusiak commentedon Mar 1, 2022
Exciting!
qknight commentedon Mar 11, 2022
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.