On Nov 3, 8:35 am, Dustin <[email protected]> wrote: > [...] > We've run well past the point of assuming anyone's going to > volunteer to maintain it, and those who've tried looking into doing it > with MS tools have all pointed out that MS tools will not support a > standard until it's 20 years old.
I already said that I will volunteer to maintain it. All I'm asking for is a little cooperation so that we don't end up with this proliferation of stale Win32 ports that currently exists. I notice that VC9 is lacking <stdbool.h> and <stdint.h>. These are not show- stoppers. I am as big a Microsoft critic as anyone and have had my fair share of gripes with VC6 while working on Boost. However, I need a Win64 port, and I want a native port, not a MinGW port. I respect Cygwin and MinGW, but using them is not the same as using native Win64 APIs directly (pthreads does not map perfectly to Windows threads, and is not even supplied by MinGW). I already found a free replacement for <stdint.h> and I'm fairly certain I can provide a suitable <stdbool.h> if it really comes down to that. I seriously doubt there are any other significant portability issues which would force major cluttering of the code. I believe that almost all of the remaining compatibility is in the threading library, which, as I described before, can be reasonably cleanly encapsulated in a thin layer. I am not interested in making a one-click Windows installer for memcached, or dirtying the codebase with such tangential issues (unless they were sequestered in an appropriate subdirectory). However, I am only going to invest the effort in porting it if I know that the Windows port will benefit from future changes. > Our goal is to get it into buildbot and then get buildbot building > stuff we can hand to Windows users that they'll be happy with. Although many users appear happy with Cygwin/MinGW, I am not. For me this is not about the build process, but rather about taking advantage of the native API. I would be happy to assist with buildbot issues if I can, but I would be happier to create a native Win64 port*. Is this option really off the table? Dave * There appear to be warnings about assigning ptrdiff_t to int...is this really 64-bit ready? This might have been from a 1.2 build and not 1.4.
