Just out of curiosity, has anyone looked at building it with the Subsystem for Unix Applications (Windows SUA)? It seems like this type of thing is exactly why the SUA is supported by Microsoft.
http://technet.microsoft.com/en-us/library/cc779522(WS.10).aspx On my SUA installation (Vista Enterprise SP1), ./configure works fine, and make churns away happily until it figures out I don't have libevent installed. Libevent has issues during make but I'm not a C programmer so figuring out what's wrong with libevent is beyond me. -Dan (first-time poster, long-time reader...) From: [email protected] [mailto:[email protected]] On Behalf Of Tom D Kat Sent: Sunday, July 12, 2009 8:51 AM To: [email protected] Subject: Re: Anyone want Memcached 1.4.x for Windows? Yeah, that DLL provides the Unix "environment" the executable would need to execute. I would also agree going with MingW on Windows would be better than Cygwin. I believe a MingW compiler on Windows would basically be a Windows-native gcc compiler and supporting toolchain. Then, it should be a matter of running make (GNU make might be needed) to build memcached. Peace... Tom On Sun, Jul 12, 2009 at 8:36 AM, Henrik Schröder <[email protected]> wrote: I was under the impression that if you compile under cygwin, you get a dependancy to their dll, and exactly that problem is what mingw solves, by allowing you to compile executables without such a dependency. As someone who runs a bunch of memcached servers under windows, I'd be skeptical about a cygwin version and would much prefer one without such a dependency. /Henrik On Sun, Jul 12, 2009 at 17:10, Michael Wieher <[email protected]> wrote: I'd look into cygwin as well as mingw if I were trying to hack a recent version of memcached to work on a M$ box. however, there are older versions which behave somewhat badly, but do work, on windows. On Sun, Jul 12, 2009 at 4:12 AM, Henrik Schröder<[email protected]> wrote: > On Sun, Jul 12, 2009 at 04:30, Dustin <[email protected]> wrote: >> >> My understanding (and I can't find anything to the contrary -- MS's >> site is just awful an makes it quite difficult to find a simple >> answer) is that VS doesn't support C99. The jellycan diff shows a few >> areas where valid C99 code was modified for C89 compliance. >> >> Supporting Windows is difficult and expensive, but there was one >> very specific constraint that I'd placed on the porting effort to >> ensure it would be acceptable and maintainable: >> >> A new platform port must touch the existing code as absolutely >> little as possible. > > Fair enough. Visual Studio doesn't support C99, and it seems they won't > support it in the near future anyway. You can apparently switch to Intel's > compiler in visual studio, but that's getting as non-standard as using > mingw, so if that approach works better for you, go for it. I remember > trying to compile memcahed way back using mingw, but failing on the > platform-specific parts that just didn't work under windows. > > Anyway, there seems to be a mingw compiler for Linux, so you could actually > do the work in your preferred environment but use the cross-compiler > instead, and then just test the resulting windows exe on your windows > machine. I dunno, maybe that approach helps with your problems? > >> >> I hope I don't sound too unwilling to compromise, but as it is we >> can't get anyone to help support a porting effort, so putting more >> onus on the existing development community, most of whom probably know >> Windows about as well as I do, is unreasonable at this point. > > That's fine, I really wish I could be of more help, but I'm really not a C > programmer, and I agree, windows modifications have to be kept as > unobtrusive as possible so that you can continue churning out new versions > without really touching the windows part, or having to worry about it. I > also looked at the patches for the windows versions of 1.2.5 and 1.2.6, and > they are pretty substantial. :-/ > >> >> Hey, you're free to do that anyway. Surely someone uses your client >> with a non-Windows server. :) > > Well, the problem is that I don't have a non-windows machine that I can run > it on. :-) > > > /Henrik > -- ~ When the great Tao is forgotten, kindness and morality arise. This email and any files included with it may contain privileged, proprietary and/or confidential information that is for the sole use of the intended recipient(s). Any disclosure, copying, distribution, posting, or use of the information contained in or attached to this email is prohibited unless permitted by the sender. If you have received this email in error, please immediately notify the sender via return email, telephone, or fax and destroy this original transmission and its included files without reading or saving it in any manner. Thank you.
