> On Tue, Feb 13, 2018 at 10:31 AM, Robin Sommer <[email protected]> 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.
Dominik
[1] https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
[2] https://www.conan.io/
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
