I would like to add one issue to the proposal. Currently, the connectivity abstraction is treated as a separate library (libconnectivity-abstraction). I believe Thiago's proposal involves getting rid of this, and I concur. There should be only one library for the stack.
I mention this because a side effect of the current artificial separation is that certain types of integration/optimization efforts are inhibited. Specifically, I want to have a single structure that represents network addresses throughout the stack. By building the connectivity library separately this is made difficult. Here is the problem: by current convention no single structure can be used throughout the stack. Structures with an OC prefix can be used in OCStack and the C++ layer, but not the connectivity abstraction. Structures with a CA prefix can be used in the abstraction layer and OCStack, but not the C++ layer. There is no way to define a structure that can be used all three places, and this results from the artificial separation of the abstraction layer. I intend to break this convention in the IPv6 work in order to clean up the processing paths. (This is not a technical issue, but a convention issue. I will include an OCStack include file, making it impossible to build the abstraction layer without the stack code.) I would appreciate integration of the sort Thiago is proposing to further support this work. John Light -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, May 06, 2015 4:59 PM To: iotivity-dev at lists.iotivity.org Subject: [dev] What are the IoTivity libraries? We began this discussion a while ago but did not conclude it. I don't remember where it ended, so let's start over. Proposal: For "lite" devices, we only build the C code, all into one *single* static library. This library is called "libiotivity-lite.a". Any other .a libraries are build artifacts and must not be installed. For "rich" devices, we build the C and C++ source code. Whether it is static or dynamic is an option chosen by the user during the run of Scons. Linux distributions will use shared libraries, but if you're writing an independent application, you'd use static (also true for iOS). I have no clue for Android. The C++ code is split into two libraries: * "libiotivity.so" (or .a or .dylib), containing discovery, connectivity, abstractions, resource manager. It includes the C SDK API. * "libiotivity-services.so" (or .a or .dylib), containing all of the services Build options: * if compiling statically, compile with -ffunction-sections and link applications with -Wl,--gc-sections * if compiling dynamically, compile with -fvisibility=hidden (C and C++), -fvisibility-inlines-hidden (C++ only) and link all shared libraries and plugins with -Wl,--no-undefined The build options should be centralised. I have no idea how to do that with Scons... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
