Hi Andor, MacOS support would be great from a developer convenience perspective - this would enable us to implement our application (that interacts with ZooKeeper) in a test-driven way. From a software development perspective, it would be great if we are able to run all the ZooKeeper native client tests, and also all of our application level unit / integration tests locally on MacOS before pushing out the changes to source control repository.
We could use Linux to develop our application due to this limitation, which would be a minor inconvenience. Lack of Windows support is a little more disappointing. This would mean we can't support features that rely on ZooKeeper for the Windows version of our application. I do not see an easy way around this. etcd seems to support a limited set of APIs through HTTP <https://etcd.io/docs/v3.4.0/rfc/>, and there is also the full-fledged support for gRPC <https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api.md> - both of which allow for possibilities to integrate a native C/C++ application with etcd. Whereas with ZooKeeper, the only viable option I see (to support a native C/C++ application on Windows) is to use JNI (with which I have limited experience, but seems like this may work). -- Deepak On Fri, Nov 22, 2019 at 4:12 AM Andor Molnar <[email protected]> wrote: > Hi deepak, > > I’m trying to refresh my memory about this. I think I’ve given up building > on MacOS, because when we call the linker at the end of the compilation, we > call it with a parameter which is not supported in OSX’s standard > toolchain. (Xcode) > > Which means I’ve managed to get around with the issue you mentioned, but I > can’t recall the details. > > Btw I usually use CentOS docker/VM to compile and validate the C client. > Why do you need native Mac support? > > Andor > > > > > > > On 2019. Nov 6., at 5:11, deepak <[email protected]> wrote: > > > > Hi All, > > > > I see that from the support matrix > > < > http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms > >that > > the native client is not supported on Windows and MacOS. I am curious to > > know if anyone has had success in getting it to work on these platforms? > > On MacOS, naturally, we are mostly interested in development, and on > > Windows, we would like to use it in production. > > > > At this point, I am hitting compile problems on MacOS (see below for > > details). > > > > On Windows, I was able to run "cmake --build ." successfully, but running > > "ctest -V" gives me "No tests were found!!!". It seems there are no unit > > tests configured to run on Windows? Or am I missing something? > > > > PS: > > Compile problems on MacOS: > > zookeeper-client-c$ make check > > /Library/Developer/CommandLineTools/usr/bin/make zktest-st zktest-mt > > g++ -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated > > -DUSE_STATIC_LIB -I/opt/local/include > > -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED -g -O2 -MT > > zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo -c > -o > > zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo > > './'`tests/LibCSymTable.cc > > In file included from tests/LibCSymTable.cc:19: > > ./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t'; did > you > > mean 'clock_t'? > > DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct timespec*)); > > ^~~~~~~~~ > > clock_t > > ./tests/LibCSymTable.h:51:29: note: expanded from macro 'DECLARE_SYM' > > typedef ret (*sym##_sig)sig; \ > > ^ > > /usr/include/sys/_types/_clock_t.h:31:33: note: 'clock_t' declared here > > typedef __darwin_clock_t clock_t; > > ^ > > 1 error generated. > > make[1]: *** [zktest_st-LibCSymTable.o] Error 1 > > make: *** [check-am] Error 2 > > > > Trying to work around this by using "clock_t" instead of "clockid_t", I > get > > past this to hit this next error: > > > > [...snip...] > > In file included from tests/TestZookeeperInit.cc:19: > > In file included from > > /opt/local/include/cppunit/extensions/HelperMacros.h:9: > > /opt/local/include/cppunit/TestCaller.h:121:28: error: no member named > > 'bind' in namespace 'std'; > > did you mean 'find'? > > m_test_function( std::bind(test, m_fixture) ) > > ~~~~~^~~~ > > find > >
