Support Fruit on Windows

[zelenij]

Good time of day,

I have noticed that at the moment Windows is not supported by the library. Do you think Visual Studio 2015 has mature enough C++11 support to compile fruit? I would like to give fruit a go, but I must support Mac, Linux and Windows. If VS2015 is good enough, you shouldn't have too much trouble compiling for it, since you already use cmake.

[poletti-marco]

Hi, I now tried compiling Fruit under VS 2015 Update 1 but their C++11 implementation is still buggy (it has improved a lot since VS 2013 though).
I filed a couple bugs:
https://connect.microsoft.com/VisualStudio/feedback/details/2197110
https://connect.microsoft.com/VisualStudio/feedback/details/2197169

Currently those prevent Fruit from compiling under MSVC.
Once those are fixed, I'll take another look (there might be other bugs/issues that currently don't appear due to those bugs).

[zelenij]

I see, thanks.

[xDPa]

Hi there,

with the new VS 2015 Update 2 these two bugs should be fixed!

[poletti-marco]

Unfortunately not, both of the bugs above are still reproducible (i.e., not fixed) with VS 2015 Update 2.

[fran6co]

Testing with Visual Studio 2015 Update 3 and I'm not seeing those bugs but it fails nonetheless in https://github.com/google/fruit/blob/master/include/fruit/impl/meta/eval.h#L103 with:

1>X:\fruit\include\fruit/impl/meta/eval.h(103): error C2672: 'fruit::impl::meta::staticOr': no matching overloaded function found
1>  X:\fruit\include\fruit/impl/meta/eval.h(109): note: see reference to class template instantiation 'fruit::impl::meta::DoEval<MetaFun(MetaExprs...)>' being compiled
1>X:\fruit\include\fruit/impl/meta/eval.h(103): error C2975: 'bs': invalid template argument for 'fruit::impl::meta::staticOr', expected compile-time constant expression
1>  X:\fruit\include\fruit/impl/meta/logical_operations.h(39): note: see declaration of 'bs'

[fran6co]

It seems that Visual Studio doesn't think the expression is constant even if it's defined with constexpr.

[xdhmoore]

Have there been any successful builds of fruit on Windows using mingw?

[zgzzbws]

I've tried to use mingw 5.3 to build it, but failed.

[poletti-marco]

@xdhmoore, @zgzzbws: I've just committed a change that makes Fruit work with MinGW.

Next steps:

• Set up CI for Windows, to make sure Fruit keeps working.
• Support MSVC when using the Clang frontend.
• Support MSVC with its own frontend (see @fran6co's open PR).

[zgzzbws]

Great, this is helpful, I will try.

[poletti-marco]

Status update: I've finally managed to get Fruit to compile and pass all tests with the MSVC compiler (by working around several compiler bugs), inspired by @fran6co's PR.
I still need to polish up my changes and make sure they don't break Linux/OS X builds, but I should be able to commit them to master next Saturday/Sunday.

[xdhmoore]

Hey, that's great! Thanks! Also, I think our avatars are cousins or something...

[BrittleFoot]

С праздником Пользователь poletti-marco <notifications@github.com> писал:

…

@***@***.******@***.***'sopenPR).Youarereceivingthisbecauseyouaresubscribedtothisthread.Replytothisemaildirectly,viewitonGitHub,ormutethethread.

[poletti-marco]

This has finally landed in master. These compilers are now supported on Windows:

• MinGW's GCC
• MSVC 2017

With the following limitations:

• When compiling with MSVC, Fruit will be compiled as a static library. Compiling Fruit as a dll is not yet supported with MSVC (but it is supported when building with MinGW). This will be fixed as part of issue Annotate Fruit's exported symbols #30. Update: limitation now removed (see my comment below)
• Older MSVC versions (e.g. MSVC 2015) don't work. I have no plans to address this ATM since MSVC 2017 will be (a bit) more widespread by the time the next Fruit version is released, and I'm not too keen in adding complexity to Fruit to workaround MSVC 2015 bugs; the workarounds for MSVC 2017 bugs are not very intrusive. I could however be convinced otherwise if the changes needed to workaround MSVC 2015 bugs are not too intrusive (PR anyone?).

I've also set up CI for both of those, using AppVeyor.

[poletti-marco]

When compiling with MSVC, Fruit will be compiled as a static library. Compiling Fruit as a dll is not yet supported with MSVC (but it is supported when building with MinGW). This will be fixed as part of issue #30.

This limitation has now been lifted (i.e. building Fruit as a dll with MSVC is now supported). It was much easier than expected, I didn't need to fix issue #30 to get there.