> 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.
Have you looked through our current win32 branch? There's one on github that's had a few cleanups since (in dustin's repo..maybe a new one in patrick's?). We would love to have help from windows folks. No, seriously, we've had so many offers and they've all gone bust. Unfortunately there're a few things that we would like to adhere to, for at least now. IE; if the current branch can be made to work with mingw32, and an external installer can be hacked up and not mess the codebase, then we'll have a branch that we can work with *now* and that we can update *now*. Then over time we can abstract more of the smaller details behind #define's toward wigglign the port to become more native. I think it'd be helpful if you could enumerate some real problems that come out of relying on mingw (note that we're not going down the cygwin route)? It'd nice for us since we can actually run these binaries and cross-compile them. Makes it a lot easier to run the test suite, for instance. Folks like me can also easily run local cross compilers and track down build issues without resorting to a shared windows machine in a VM somewhere. If we're going to run into real troubles from using mingw instead of relying on "native" for what few system calls memcached actually makes, we'd love to know about it sooner than later. > 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. It would be highly appreciated if you could relax a little on your requirements and work with us. I'm not saying VC9's not out of the question either, but you'll see how much work it would require? We're not asking about making an installer at all.. I imagine someone at northscale will bother with that. I can't be arsed either, especially since I'm not paid to make it work ;) Thanks, -Dormando
