Windows support for folly

[auroraeosrose]

Allow folly to build and work on windows systems - using

1. Visual Studio 2013 [VC++12](and above) compilers (anything below is missing too many c++11 features)
2. Clang on windows llvm 3.4 and higher
3. MinGW-w64 4.8 and higher
   with support for Windows 7 and higher operating systems (this includes server 2012 and 2012 r2)

This is necessary to allow hhvm to link and use folly

Visual Studio 2013 is missing several c++11 features which folly uses, which will make porting a bit of a pain. Currently these have been identified as:

1. constexpr
2. noexcept
3. default move/assign methods (these do work but you have to write them by hand, =default will fail)

In addition windows in general is missing several posix apis in use. However, only very platform specific futex and elf/dwarf features do not have analogs in the windows apis. So these can be "faked" with posix api wrappers, and perhaps later with pluggable direct calls into windows apis. Even the futex use could be replaced with some of the new threading and atomic calls available since windows 7.

All the currently in use dependencies compile and work properly on windows

1. double-encoding (using 2.1)
2. glog
3. gflags
4. pthreads (pthreads-win32 which works on 64 bit now or winpthreads)
5. snappy
6. zlib
7. lzma (via xz utils)
8. lz4
9. boost
10. libevent
11. gtest

This will necessitate a friendlier build system (that's preferably a bit more up to date than the current autotools system), builds of dependencies for deps that don't distribute pre-build binaries (should always be sure that runtimes match), fixes for c++11 features not implemented in msvc, and posix wrappers/adjustments for platform dependent implementations for folly features.

[auroraeosrose]

The first portion of this is #53 which adds a cmake build system for folly - it will allow cross-platform and cross compiler support for folly builds.

[auroraeosrose]

#55 replaces the use of constexpr with a macro

[auroraeosrose]

#56 replaces noexcept with a macro

[jdelong]

The solution on #2 seems reasonable to me, but I am not so convinced replacing constexprs with const is going to work out for some parts of the hhvm code---constexpr also lets you use things in places where const doesn't, and I'm pretty sure there's at least a few places where make use of that. Also, writing default move ctors and move assignment operators by hand seems pretty undesirable from a code quality perspective. (Particularly if it's guarded behind an ifdef---it won't really be tested much.)

I wonder if it's maybe better just to drop VC++12 from the plan for supported compilers?

[auroraeosrose]

The constexpr stuff stuff no doubt will break in parts of the hhvm code. There will probably need to be two macros for constexpr at some point, one that defines to nothing, and one to constexpr. Chromium, mozilla and others take this route.

And yes writing default move ctrs and assignment operators suck - however this is used in 2 places in all of the folly code currently. If the usage can stay to those two locations until MSVC-NEXT is released and 2013 can be ditched it will keep the headaches to a minimum.

Some problems with choosing to defenestrate vc++12 support

1. You're sending a message to windows users that the default, commercially supported compiler for their platform doesn't matter - it would be similar to not supporting gcc for linux and instead telling them to only use clang... yes it works but...
2. VC creates faster, tighter, and arguably better code than gcc and clang on windows - especially when using PGO optimizations and on 64 bit
3. MSVC will catch up (the CTP already supports quite a bit including constexpr), by choosing not to support it now you're getting around the constexpr and noexcept issues - but there are other things that will be needed that won't be addressed now - you just push work off to "the future"

[auroraeosrose]

gcc specific attribute functionality is abstracted out in #57

[ki7chen]

I've done porting Benchmark.h, Conv.h and Range.h to MSVC, its really painfull and some feature must be removed to make the compiler happy.

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[ghost]

Thank you for your patience. After 30 days with no updates from the core team, we're closing out the issue. If you're still experiencing the problem described, please reopen the issue - thanks!