One more point below. > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Lankswert, Patrick > Sent: Wednesday, February 25, 2015 2:45 PM > To: Macieira, Thiago; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Library names for IoTivity > > Hi, > > > -----Original Message----- > > From: Macieira, Thiago > > Sent: Tuesday, February 24, 2015 4:17 PM > > To: iotivity-dev at lists.iotivity.org; Lankswert, Patrick > > Subject: Re: [dev] Library names for IoTivity > > > > On Tuesday 24 February 2015 12:58:12 Jon A. Cruz wrote: > > > This seems to me that a separation between C and C++ parts of the > > > core might be warranted. For the single-threaded case that would > > > mean not building the C++ lib. > > > > > > The current proposal of a single library would presumably address > > > this by merely selectively disabling inclusion of the C++ code by > > > build configuration wizardry. > > > > > > Making the C and C++ parts into two libraries would simply build > > > configuration and maintenance. However our codebase is probably > > > small enough not to require this complexity yet. Then later we could > > > split into two libs and perhaps a compatibility lib that keeps the > > > original name but references both of the new ones. > > > > Another advantage is to ensure we don't have any leakage of C++ code > > into the C SDK, if we do the split. > > > > A disadvantage of the split is the overhead caused by having mutliple > > libraries. There's at a minimum 4k overhead of non-sharable data and > > the symbol resolution is O(n) on the number of libraries. > > > > I did mention this to Pat and he, as the maintainer of this particular > codebase, > > said he prefers a single, merged library. > > > > Pat, do you want to change your mind? > > I do not think so, I think that on a given platform (say linux system) there is > little benefit to splitting the shared library and a cost to coordinating two > libraries. Even as a static library, multiple libraries seem to add unneeded > complexity. > > On platforms, like Arduino, the C++ code will simply not be included in the > static libraries.
I want to add that I am only talking about the base stack (C/C++) libraries. I think that the service should be organized as Uze sees fit, but I think that bundling them in the core stack library would not be the right thing. Pat -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150225/f463cd47/attachment.p7s>
