On Nov 4, 11:53 am, "David H." <[email protected]> wrote:
> No, but if that's a good place to start, I will check it out. Patrick's branch is healthier and known to work at this point (though not entirely complete): http://github.com/CaptTofu/memcached/tree/win32 > I understand that none of these problems are concerns of you as > maintainers of this product. However, I would not be surprised if > there were many other users out there who would dearly love a native > Windows port and have some of the same political challenges to deal > with that I do (not having to use gcc, even though we know that it's > also a better product in many respects). Do understand that nobody is arguing that we don't want to do the absolute best we can do on any given platform, but if it creates too many maintenance or other issues for the project in general, we'd like to back off some. We're obviously all unix guys here, so doing something unixy makes sense to us. I'm quite happy to have someone coming in from a Windows background who will point out which things we're thinking about doing are "bad." Don't expect us to completely understand why they're bad, but do understand that sacrifices will have to be justified. > Those are valid concerns. If I were to create a Windows port, I would > want to maintain test parity and I could provide the Windows build & > test environment if necessary. We'd certainly be grateful for that. We *almost* have a Windows builder ready to be spun into the regular pool, but the code's not quite there yet. Additional expertise in that area is certainly helpful. > compatibility layer (I have no idea). Even if it is trivial, there is > also the fact that MinGW is not a native build environment for most > Windows shops (this is the bigger problem, and likely a showstopper > for my shop). Also, there will necessarily be fewer opportunities for I am a bit dubious of this claim. You don't have to build it, we can build it and just give you something you can run. You don't necessarily know what tools people use to build all of the software you run, do you? > best or fastest way to do things (and why are you guys using C99 if > you don't want memcached to be wickedly fast?). Honestly, C89 -> C99 provides a lot of convenience. C99 is a nicer language. > > 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? > > Yes, but I'm volunteering to do most of it. Why? Because if I get a > successful native Win64 build running in my project, then I will have > a strong, vested interested in making sure the Windows port stays > current. From my perspective, I'm taking a calculated risk on a > strategic investment. From what I can tell, the worst outcome for you > is Yet Another Windows Port that perhaps does not get maintained, or > simply continuation of the status quo (that's what source control is > for, after all, no?). If you go through the history, you'll see that we've been begging for someone like you for quite a while. Dormando's concern, however, is what it costs the rest of us. > I would also like to point out that memcached could easily remain a C- > within-C++ app which avoids all the C++ features while taking > advantage of the wider availability of conforming C++0x compilers than > C99 compilers. There are no uses of 'class', and even the void*->T* > conversions can be trivially fixed with explicit C-style casts (and > one could argue that from a documentation perspective, this is A Good > Thing(TM)). The only major C99 feature that might be missed is VLAs, > and I don't recall seeing any in the code. I don't know that it's necessarily a language thing. There are certainly areas where C++ would make the code better and we shouldn't avoid them dogmatically if we're building stuff in C++. However, memcached will not currently build under a C++ compiler. I tried one night and it wasn't very fun. We do have VLAs and late defined variables and nested struct initializers and other things that make stuff easier. If memcached did build under a C++ compiler, we may have issues loading engines dynamically. That would be... unpleasant. I don't have experience dynamically loading C++ code, though.
