On Wed, Feb 14, 2018 at 9:52 AM, Dominik Charousset
> CAF headers are included in public broker headers.
Good point, I didn't remember that, it does complicate the situation.
Though maybe it's still only more a problem for the less common
use-case of someone actually wanting to use libbroker themselves. I
think more commonly someone just wants to get Bro up and running and
so there could possibly get away with static linking and not bothering
to install headers.
> Moving *all* CAF headers out of Broker headers could solve this, but it
> requires a lot of pimpl boilerplate code
That does sound like a bunch of work someone probably would not enjoy doing :)
Though Broker originally used to pimpl everything and that approach
worked and seemed fine at the time.
> Completely hiding away the CAF actor system also takes away any opportunity
> for integrations.
Yeah, that all sounds less desirable and not sure what could be done about it.
>  https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
Maybe as a last resort. Generally, I think I'd rather not -- every
time I've tried to use them or seen them used there's been a
"flakiness" to them that I wish I could describe in more logical
terms. I also think every project where I've tried to use a CMake
External Project myself has never actually made it into an actual
release or at least any that are still used at all. I'm not sure
there's a relation, though it also doesn't make me feel great about
the prospect of using that same approach here.
>  https://www.conan.io/
Could be something to consider/evaluate; never used it myself.
At this point, I'd rather just stick to the current situation until
it's actually clear what problems people will have (or take the time
to complain about), if any. Then once pain points are better known,
decide on what would improve the situation.
bro-dev mailing list