How do I build Cgreen on windows?

[anujkumar-df]

Is there any official guide how this framework can be build on windows ?

I have some hard time trying to build.

[thoni56]

That surely depends on your toolchain. VisualStudio? I haven't done that myself. Looks like @matthargett (and possibly @gardenia) did some work for windows compilability some years ago, but I don't actually know what environment he used.

But you are correct that Cgreen misses some information on pure windows usage.

[gardenia]

we were building on cygwin. IIRC it was working ok at the time. never tried VS. but it is C99 so it should be able to be convinced to build without too many problems (although I have a feeling that I remember reading that VS didn't support some C99-isms until very recently) . I'm vaguely aware that cmake can make VS project files but I have no firsthand experience of that.

[thoni56]

@anujkumaraurea if you have solved your problem, we'd be interested to collect that info and make it available to others. If not, perhaps you could give us some details on what you have tried and what you are experiencing.

[anujkumar-df]

@thoni56 Unfortunately no, so I moved to catch framework.

[thoni56]

@anujkumaraurea ok, I'll keep this issue open to remind us to collect more info and write some instructions at some point.

[d-meiser]

@thoni56 I was playing with building cgreen on windows over the weekend. I was able to get pretty far. But a bit of effort is required to get mocking to work right. Would you be interested in a pull request where mocking is disabled on windows? I don't use mocking at the moment so have little motivation for fixing it at this time. With my changes it would be possible to provide binary installers for folks on windows.

[thoni56]

A PR with disabled mocking but with updated documentation that explains the building process and mentions the disabling of mocking would be perfectly acceptable!

What is required to get mocking to work?

[d-meiser]

Ok, I'll clean up my changes. There were a few changes that require discussion (for example symbolic links in the git repo don't work well for me on windows). Will update documentation with build instructions.

The problem with mock() were related to C preprocessor in visual studio. There are some comments in the code indicating that the version used on windows works around some quirks in VS 2012 but this code gives compiler errors with VS 2015. I'm not sure what the right fix is

[bpetto35]

I have looking on the code and the fork. I still have issue because Visual Studio expect to have export symbols defined. GCC by default export everthing and MSVC export nothing by default.

@d-meiser, how did you fix it, if you did ?

[d-meiser]

Hi @bpetto35,

I haven't done anything regarding symbol visibility. If I remember correctly I just used the static libraries. You could do that as a workaround.

Generally speaking symbol visibility can be addressed with a module definition file (".def" file) or by annotating the public symbols with __declspec(dllexport)/__declspec(dllimport). Since our build system is based on cmake it would be very easy and nice to go that latter route using GenerateExportHeader. This would allow us to also hide non-public functions with gcc and clang using -fvisibility=hidden.

For what it's worth I have a couple of Windows fixes in my win32-fixes branch. But I never tested or used it sufficiently to submit a pull request. My long term goal was to create a conan binary package for Windows. That would probably be the easiest way for people to use cgreen on Windows.

I don't have a lot of time to work on my hobby projects these days unfortunately. But if you have any specific issues or questions I may be able to help.

Cheers, Dominic

[solvingj]

Its quite a coincidence that found this thread while creating a conan package for cgreen. I haven't spent any time looking into why yet, but for me, there are currently 9 errors when trying to build with Visual Studio2017 with CMake 3.1.0, when using:

cmake .. -DCGREEN_WITH_UNIT_TESTS=False
cmake --build .

They're all variations of the first one: d:\sources\git-conan\cgreen\include\cgreen\internal\cgreen_time.h(5): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory [D:\sources\git-conan\cgreen\build\src\cgreen_shared.vcxproj]

Whatever conditional is used to include the windows_headers directory doesn't seem to be working: include/cgreen/internal/windows_headers

I tried from Master and 1.1.0.

I don't see fixes for this in @d-meiser 's commits on his fork, so not sure why he didn't get this error. Maybe it's a regression since then?

[d-meiser]

@solvingj there are a few fixes for the unistd.h issues in this commit:

https://github.com/d-meiser/cgreen/commit/d74fe17f06dcd0bda112e6722796913e4c074db9

This commit is on the following branch: https://github.com/d-meiser/cgreen/commits/win32-fixes

As I mentioned in my previous comment I haven't tested this thoroughly. But perhaps you can use it as a starting point.

[solvingj]

Thanks again @d-meiser .

In retrospect, there's a fundamental issue with this project in that native Windows support does not appear to be receiving first-class support from the core team. Until that happens, this will likely be a turnoff for most dev's who are looking a fully-supported cross-platform solution.

I would say that one of the first steps in remedying this situation would be to add Windows CI builds. It's not terribly difficult, so my best guess is that nobody on the team uses Windows, and no users have brought it up outside this ticket, and that's why it's not already in place. In any case, TravisCI now supports windows builds, so it should be a matter of adding a few lines to the TravisCI files, and fixing any remaining errors. Also, there's always Appveyor if that doesn't work out for some reason related to the "newness" of windows support on Travis.

Keep up the great work!

[thoni56]

Thanks for your comments! And you are probably right in your observation about noone is using Windows.

But I also think that an important reason for this not being addressed more is the fact that ”Windows” is somewhat ambigous since there are a number of flavours of getting software compiled on/for Windows.

I frequently use Cygwin with cross-compiling and then first compiles the tests in native Cygwin. And this of course works fine.

Then you have MinGW in two flavours, Visual Studio GUI and the command line versions of Microsofts compilers.

At least to me it makes me unsure where to start.

So any help and/or pointers are appreciated.

[solvingj]

There's no reason all three can't/shouldn't work. We have many packages where they all do. However, far and away, Visual Studio and MSBuild are the most important, so that's where anyone should start.

Here's a .travis.yml example using CMake that you can reference if you want to add more configurations to your CI. It has Windows, macOS, and Linux.

https://github.com/solvingj/libhandler/blob/add_travisci/.travis.yml

I can't take credit for most of it. I derived it from this really nice C libraries, and just got the Windows bit working.

https://github.com/saprykin/plibsys/blob/master/.travis.yml

Of note, the author there has done much more extensive windows testing using appveyor, including MinGW, cygwin, etc. However, that yml file is pretty complex, so you may just want to start by expanding your travis build.

https://github.com/saprykin/plibsys/blob/master/appveyor.yml

[thoni56]

In https://github.com/cgreen-devs/cgreen/commit/a96be463285a9242e5d18cacb4e9ddefcd637b8a I've replaced the symbolic links with plain

#include <file.c>

This should get rid of the problems with symbolic links on Windows, MSYS2 and Cygwin.

(On Cygwin there was a workaround, but that required that you had configured your Cygwin in a particular way, now that should also be a thing of the past.)

[thoni56]

I think I need to request the help of @matthargett and/or @d-meiser ...

There is now a branch, building_on_msys2_mingw32, on which I have been attacking this in an attempt to build on Msys2/MingwXX, i.e. an WIN32 environment. (Cgreen works flawlessly in Msys2/Posix, of course.)

It is now very simple to build cleanly, just clone, checkout the branch and do make, given that you have an Msys/MingwXX environment setup. (See BUILDING.md for copyable instructions...)

Problem is that the Windows simulation of fork and messaging crashes. You can run tests with CGREEN_NO_FORK=1 so all the logic works, including the reflective runner cgreen-runner.

One of the tests for the xml_reporter which only does reporter->start_test() and reporter->finish_test() (never calls a test) fails, which to me smells like it is the messaging that is the problem, rather than the test forking.

The new file BUILDING.md (on that branch) describes where I'm at, but since my Windows API fu is not up for snuff, I'm a bit lost.

What I've found is that ReadFile in cgreen_pipe_read always returns zero bytes read, which is interpreted as a non-working connection. So, again, my suspicion is that the communication channels/handles are not setup correctly.

[chenyulue]

I think I need to request the help of @matthargett and/or @d-meiser ...

There is now a branch, building_on_msys2_mingw32, on which I have been attacking this in an attempt to build on Msys2/MingwXX, i.e. an WIN32 environment. (Cgreen works flawlessly in Msys2/Posix, of course.)

It is now very simple to build cleanly, just clone, checkout the branch and do make, given that you have an Msys/MingwXX environment setup. (See BUILDING.md for copyable instructions...)

Problem is that the Windows simulation of fork and messaging crashes. You can run tests with CGREEN_NO_FORK=1 so all the logic works, including the reflective runner cgreen-runner.

One of the tests for the xml_reporter which only does reporter->start_test() and reporter->finish_test() (never calls a test) fails, which to me smells like it is the messaging that is the problem, rather than the test forking.

The new file BUILDING.md (on that branch) describes where I'm at, but since my Windows API fu is not up for snuff, I'm a bit lost.

What I've found is that ReadFile in cgreen_pipe_read always returns zero bytes read, which is interpreted as a non-working connection. So, again, my suspicion is that the communication channels/handles are not setup correctly.

Are there any plans to merge the win32 branch into the main branch?

[thoni56]

To merge the Windows brach we need someone who develops on Windows frequently and has enough knowledge about at least one version of the Microsoft toolchains too modify the build scripts.

None of the currently active maintainers fullfil those criterias. If that is you, great! If not, do you know someone that can help?