On 4 December 2015 at 10:18, Mike Leach <Mike.Leach@arm.com> wrote:

> Why include the ARM in there? The usual convention is a single string, not
> multiple words - I'd have expected libopencsd.so and libcstraced.so (why are
> they separate libraries BTW).

ARM - architecture - as per Intel PT being lib ipt. Not crucial I guess but descriptive.

I expect that's deduplicating for a collision on "ipt" which is a very short name. OpenCSD doesn't have that issue.

As for the single word convention - see the boost C++ libs! - though in our case multiple words does separate the C-API from the main lib. i.e. libarm_cstraced.so is the C++ lib, libarm_cstrace_c_api.so is the C API wrapper.

Boost is a bit fun in general though, I'm not sure it's an ideal model.

Separate libs as the C API is an optional wrapper on top of the main C++ library. C++ application developers can just use the main lib and get additional flexibility of direct manipulation of the C++ decoder objects should they want that.
The C API currently consists of the interface to the DecodeTree object plus a few additions.

Why would any C++ user care if they pull in a small layer of wrapper code? If things were the other way around and there were a C++ wrapper around a C library there would be an advantage in keeping the C library out of the C++ ABI dependency chain but that doesn't apply here since the C library is going to pull in the C++ dependencies anyway.