I have some trouble when run project with cmake. the errors listed as follows. Can anyone give me some advices about it,please?

cong@pc:~/Program/zookeeper-cpp$ cmake .
-- Software Version: 0.2.3
CMake Deprecation Warning at CMakeLists.txt:21 (cmake_policy):
  The OLD behavior for policy CMP0037 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Error at cmake/modules/ZooKeeper.cmake:30 (message):
  Could not find Apache Ivy
Call Stack (most recent call first):
  CMakeLists.txt:30 (include)


-- Configuring incomplete, errors occurred!
See also "/home/cong/Program/zookeeper-cpp/CMakeFiles/CMakeOutput.log".
cong@pc:~/Program/zookeeper-cpp$ cmake --version
cmake version 3.17.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).
cong@pc:~/Program/zookeeper-cpp$ 

Idea : zk::connection should provide a way to reconnect after a connection is loss,
as well as an atomic state

Considering the following example :

zk::connection con = zk::connection::connection("zk://addr:port/?opts");

// somewhere else ...

switch (con->state())
{  // handle some connection loss cases
   case zk::state::closed: [[fallthrough]];
   case zk::state::expired_session:
   {
	reset_connection(); // smthg like `con = zk::connection::connection("zk://addr:port/?opts");`
	break;
   }
   default:
	break;
}

In the sample above, the issue is the switch/cast is error-prone, as erasing con content may result in invalid con->state() read in a concurrent context.
This force the user to create some blocking operation using memory barriers and perhaps condition_variales, to ensure no wrong states are evaluated during connection reset.

In my opinion :

auto client = zk::client::connect(/*args...*/)

should be equivalent to :

auto client = zk::client{zk::connection::connect(/*args...*/)}

Having zk::client::connect::get blocking the current thread as long as the client is not connected is not a viable option as we do not have cancelation in the current future implementation.

Also, for convinient error management, I wrapped connection into an IIFE :

auto client = []() <waiting_policy>
{
      auto future = std::move(zk::client::connect(url));
      waiting_policy(future);
      return future.get();
}();

Where waiting_policy implements an operator()(std::future&) which internaly calls std::future::wait, wait_for, or get, with a failure behavior.

For instance :

template
	<
		typename duration_type = std::chrono::seconds,
		typename = std::enable_if_t<details::detect::is_chrono_duration_v<duration_type>>
	>
	struct timeout
	{
		template <typename future_type>
		void operator()(future_type& arg) const
		{
			if (arg.wait_for(duration) != std::future_status::ready) // timeout || deferred
				on_failure();
		}

		template <typename Fun>
		timeout(duration_type&& duration_arg, Fun&& failure_behavior)
			: duration{ std::forward<decltype(duration_arg)>(duration_arg) }
			, on_failure{ std::forward<decltype(failure_behavior)>(failure_behavior) }
		{   // clang does not properly resolve dependent type duration_type in this context
		}

	private:
		const duration_type duration;
		mutable std::function<void()> on_failure;
	};

FYI, here is the way I quick-fixed it using a really dirty approach :

CMake :

• ZKPP_FUTURE_USE_CUSTOM with everything like ZKPP_FUTURE_USE_STD,

but :

• ZKPP_FUTURE_INCLUDE pointing to a custom file, which includes <future>, but also define something async, forcing its std::launch policy to std::launch::defered

#pragma once

#include <future>

namespace stl_override
{
    template <class Function, class ...Args>
    static /*[[nodiscard]]*/ auto async(Function&& f, Args && ... args)
    {
        return std::async(
            std::launch::deferred,
            std::forward<decltype(f)>(f),
            std::forward<decltype(args)>(args)...
        );
    }
    template <class Function, class ...Args>
    static /*[[nodiscard]]*/ auto async(std::launch /*policy*/, Function&& f, Args && ... args)
    {
        return std::async(
            std::launch::deferred, // force argument, discard `policy`          //    <--------- here !
            std::forward<decltype(f)>(f),
            std::forward<decltype(args)>(args)...
        );
    }
}

Then, ZKPP_ASYNC_TEMPLATE is set to stl_override::async

Really need some CMake's option directive to select which target are about to be part of the build, and which not.

For instance, some projects which depends on Zookeeper-cpp may only depends on the client.

Please consider the strong exception guarantee, e.g non-throwing move-assignement/move-assignement.

Current code :

class watch_result final
{
    watch_result(watch_result&&) = default;
    watch_result& operator=(watch_result&&) = default;
}

So

static_assert(std::is_move_assignable_v<watch_result>); // ok
static_assert(std::is_nothrow_move_assignable_v<watch_result>); // KO

Please consider using noexcept for strong exception garantee :

watch_result& operator=(watch_result&&) noexcept = default;

Sorry @bonifaido just bumping the above :point_up: :slightly_smiling_face:

Happy to put up a few PRs to get this going but wanting to see if you have any thoughts/preferences before jumping in.

Ps : The issue (if an issue it is for you as a library designer), is related to https://en.cppreference.com/w/cpp/thread/future/%7Efuture to me

Is there a way to cancel connection ?

For instance, when trying to connect to a Zk server that is not running, how can we abord the connection attempt ?

According to the following snippet,

auto main() -> int
{
	try
	{
		auto client_future = zk::client::connect("zk://127.0.0.1:2181"); // local server which is currently stopped
		using namespace std::chrono_literals;
		const auto wait_result = client_future.wait_for(2s);
		if (wait_result != std::future_status::ready)
		{
			throw std::runtime_error{ "timeout 1" }; // reached, but after throw(),
                                                                                    // the code flow go back to `auto client_future = zk::client::connect("zk://127.0.0.1:2181");`
		}
	}
	catch (const std::runtime_error& error)
	{       // never reached
		std::cerr << "error : " << error.what() << '\n';
	}
	return 0;

Where is the CMake target mentioned in the documentation ? Not implemented yet ?

I'd like to use it to implement some UTs.

Ps : Cannot set a label ?

Fixes #113.

@joshleeb your PR has been migrated to https://crates.io/crates/zookeeper-async. I hope you don't mind.

While this project is great, it lacks documentation about how to integrate it into others CMake projects as dependency. (My bad if it already exists somewhere else, so my point would be that it should be placed in the README.md)

A few samples should do the tricks :

• FetchContent (simple project add_dependency + target_link_library)
• Compilation options (ZKPP_BUILD_SETTINGS_BUFFER, ZKPP_BUILD_SETTINGS_FUTURE, etc.)
• How to build (or exclude from build) specific targets : tests, server, etc.