Hartmut Kaiser

Current status: - `boost::chrono` is not used anymore, - `boost::context` is used on certain platforms only. - `boost::thread` is not be used anymore You forgot to mention `boost::asio` in your...

> program_options was just an example. the idea was not to introduce a new external dependency, but to simply add an include file to hpx::util::cxxopts or something of that kind....

> For performance counter names - does having a parser buy much more than a regex would give us? I don't think the performance counter names could be 'parsed' using...

> The thread allocator is one that you found on the web and is not a supported library What I proposed as a PR is a major rewrite of an...

>> We should just submodule the boost libs we need and include them in our build system. Then it looks like we're free of boost... > > And this is...

> 1. How about actually copying `program_options` into our repo. It ~hasn't had updates in a few years and~ (not quite true...) has only a few other boost dependencies that...

> Does the performance counter syntax incur a runtime cost that is significantly improved by using boost spirit? This seems like the one place where it might make a noticable...

Taken from here: https://gist.github.com/K-ballo/7b551d71487bdf34d0b25aa034e399a5 ``` COUNT | LINE ----------------------------------------------------- 11 | 11 | 10 | 9 | 9 | 8 | 8 | 6 | 6 | 5 | 5...

Does it fail if you specify `-DHPX_WITH_ASYNC_MPI=On` to cmake explicitly?

As a first step, we could create interface-compatible classes which simply use a spinlock to ensure data consistency. That shouldn't take too much time.