I agree that avoiding the multiple build systems would be nice.
 Unfortunately, though, windows is an animal unto itself.  I would
be hesitant to change the whole build system over to cmake just for the
ideal situation that there be one build system for all platforms.  I have
seen projects that maintain the win32 build separate from the *nix builds,
and this does not seem to be too onerous.  I'm flexible, but will probably
in the end use the same tools to build as I do now.

One remaining critical issue is the zookeeper_close() call while the client
is in the CONNECTED state.  Even in the single-threaded setup this call
blocks when connected instead of using zookeeper_interest() and a callback,
as seems appropriate.  The current code can cause an infinite loop.  For
this port to be serious, we would need this cleaned up.

On Tue, Aug 31, 2010 at 1:09 PM, Patrick Hunt <phu...@gmail.com> wrote:

> Hi Ben, that's great!. There has been some interest in this, however I'm
> not aware that anyone has done a port.
> Here's how to contrib:
> http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
> basically you would create a JIRA and attach your patch against latest
> trunk svn. The committers will review and provide feedback.
> It would be great to not have to manage multiple build systems for the c
> code. Should we switch to something like cmake instead of autotools? Or will
> that work for you (win/cygwin/unix based build I mean).
> Patrick
> On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins <ben.coll...@foundationdb.com
> > wrote:
>> I have a working win32 port of the C API, not depending on Cygwin, that
>> supports the "single-threaded" model of network interaction.  It compiles
>> in
>> Visual Studio 2010 and works on 64 bit Windows 7.   There are know issues,
>> and it is in it's initial stages; but it has been successfully used
>> against
>> the java server.
>> I am happy to provide patches, but would like any pointers to efforts
>> already undertaken in this area, or folks to communicate with about this.
>> Thanks,
>> --
>> Ben


Reply via email to