Hello all I talked to Pat here at the OIC meeting and we came to the conclusion that both the C and C++ parts of the core (discovery, connectivity & security) codebase should be in one single library. Therefore, we propose two build modes:
==== Proposal ==== 1) shared library: libiotivity.so.1 / iotivity1.dll, thread-safe, including both parts and linking to the C++ runtime. Implies -fPIC and - fvisibility=hidden. 2) static library: libiotivity.a / iotivity.lib, thread-safe but no -fPIC. Given the size of the library today, I suggest we simply build both targets by default. 3) static library without thread-safety -- non-default, so requires options to the buildsystem to be enabled. We don't know how the services codebase should be deployed. We're looking for Uze, Jinguk and Mats to give their feedback. ==== Rationale ==== On systems where more than one application or process will make use of IoTivity, it makes sense to have a shared/dynamic build. I expect this to be the rule on devices running Linux and shipping IoTivity as part of the distribution. Additionally, regular Linux distributions have strict rules about bundling of code, so shared libraries are mandatory. On systems that may run multiple IoTivity applications but where IoTivity is not shipped as part of the system (think Android and iOS), app developers are given the choice of using the dynamic library or using the static one. I believe most users will select the static library, as it eases deployment. On systems where a single application runs IoTivity, the static library should be the one used. This includes memory-constrained devices, whether they run Linux or not. For the same reason, the C SDK portion of the static library should not trigger require the C++ runtime and should have minimal external dependencies. Systems without support for threads are expected to be very memory constrained. Therefore, only the static library should be enabled. In other words, disabling thread support should disable the C++ layer and the dynamic library too. ==== note ==== Note on -fvisibility=hidden: this implies adding export macros to the API. If the headers are the same, this will require the user to define a macro indicating whether they are linking against the dynamic library or against the static one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
