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. >
