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.
I'm currently looking at issues regarding windows DLLs vs Linux .so. In a linux shared object, everything is exported by default - so all is well, in windows DLLs nothing is exported by default, so we need to explicitly export stuff hence lots of interesting code such as this from rctdl_c_api.h (the main C-API include file )
/* ensure C bindings */
#ifdef WIN32 /* windows bindings */ #ifdef _RCTDL_C_API_DLL_EXPORT #ifdef __cplusplus #define RCTDL_C_API extern "C" __declspec(dllexport) #else #define RCTDL_C_API __declspec(dllexport) #endif #else #ifdef __cplusplus #define RCTDL_C_API extern "C" __declspec(dllimport) #else #define RCTDL_C_API __declspec(dllimport) #endif #endif #else /* linux bindings */ #ifdef __cplusplus #define RCTDL_C_API extern "C" #else #define RCTDL_C_API #endif #endif
So the windows C-API DLL explicitly exports all the C-API functions - handy for those requiring a nice C interface - especially when binding to scripting languages such as python etc. So on the windows side, this DLL is required if we are to achieve a scriptable interface - which was one of our (ARMs) goals. The windows C API DLL currently statically links the C++ lib.
The equivalent code in the C++ library would be quite extensive - all the classes need to be exported - so at present I have not done that. I am not 100% sure when this will be done. Thus on windows the C++ and C-API are managed as separate projects - so too in linux for consistency. I also like the separation - two header files / two libraries (albeit with a dependency chain in linux) - the user chooses to use one or the other of the interfaces, but not both.
So the current goal of all this is to get .so working in linux to ensure that the library access is acceptable to the perf development - and other linux devs who prefer C interfaces, and decide on the final windows strategy later.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: Mark Brown [mailto:broonie@linaro.org] Sent: 04 December 2015 10:46 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: Library names.
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.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.