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.