> On Tue, Feb 13, 2018 at 10:31 AM, Robin Sommer <ro...@icir.org> wrote:
>> I was wondering the other day if we could add CAF as submodule to
>> Broker

I can understand where you’re coming from. Dependency management in C++ is 
lackluster, to say the least. However, baking CAF into Broker in this way is 
not trivial and can break many, many things.

CAF headers are included in public broker headers. This means users of 
libbroker must be able to find those headers in the system paths. You could 
install CAF headers via CMake along the Broker headers, but that would override 
any other local CAF installation. Worse, if a user installs CAF from a 
different source afterwards you could produce an ABI clash when compiling a 
libbroker application with the wrong CAF headers. It might even compile fine, 
as long as the API remains compatible, but produce very nasty hard-to-debug 
errors at runtime.

Moving *all* CAF headers out of Broker headers could solve this, but it 
requires a lot of pimpl boilerplate code to make everything CAF opaque. 
Completely hiding away the CAF actor system also takes away any opportunity for 
integrations. For example, we are currently thinking about how we could 
integrate Broker with VAST. Locking away the actor system would take away many 
benefits of integrating Broker. For one, we would have to run two distinct 
actor systems in the same process instead of using one and getting all the 
scalability benefits from it. Two actor systems means two schedulers that 
either constantly fight for resources or leave performance on the table. If 
each scheduler gets only half of the available HW via config that would waste a 
lot of CPU bandwidth if one scheduler is idle but the other at capacity. 
Performance aside, not having access to the Broker actor system would 
potentially require us to duplicate a lot of code for using Broker types in 
VAST. Of course this is also prone to error now, because any change in Broker 
no longer automatically updates the serialization code in the now detached 
actor system.

Long story short, doing this would shut a lot of doors for us. Did you consider 
using something like CMake’s External Project [1] feature or Conan [2]? There 
is a Conan recipe for CAF (contributed by a user a while ago) that could make 
life for Bro users easier. I’m happy to work on the recipe if it isn’t working 
out of the box right now, if that would work for you as an alternative.


[1] https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
[2] https://www.conan.io/
bro-dev mailing list

Reply via email to