Apache Celix is a framework for C and C++14 to develop dynamic modular software applications using component and in-process service-oriented programming.
This PR adds the generation and usage of an export header and its macros to the libraries etcdlib, dfi, utils and framework.
For the updated libraries the default (C) symbol visibility is also set to hidden.
As result almost all headers for the libraries etcdlib, dfi, utils and framework are updated to ensure the correct symbol visibility.
This is the first step for the issue #442.
The export headers are generated using the CMake function generate_export_header and for dfi, utils and framework the header filename is configured as celix_<lib>_export.h and the base macro name as CELIX_<LIB>.
The utils and framework libraries also have an OBJECT library variant (needed for error injection). For now I updated the CMakelists.txt file to configure the SHARED / OBJECT libs in 2 different ways:
The current way of configuring the _obj OBJECT library and having the SHARED library depending (link PUBLIC) on the _obj library.
Using a cmake function to configure both the OBJECT and SHARED libraries and generating a export header for both library (with the same filename and macro names).
The different ways can be toggled using the CMake variables CELIX_UTILS_CMAKE_CONFIGURE_ALT_OPTION and CELIX_FRAMEWORK_CMAKE_CONFIGURE_ALT_OPTION, but before merging the PR I would like to choice one way and remove the other.
The reason I added an other way of configuring the SHARED and OBJECT library for utils and framework is that the generated export header use a #ifdef to distinguish against building and using a library and IMO to let this work as intended both the OBJECT and SHARED library should have their own export header.
See the following snippets from the utils and utils_obj generated export header:
# ifdef utils_EXPORTS
/* We are building this library */
# define CELIX_UTILS_EXPORT __attribute__((visibility("default")))
# else
/* We are using this library */
# define CELIX_UTILS_EXPORT __attribute__((visibility("default")))
# endif
# ifdef utils_obj_EXPORTS
/* We are building this library */
# define CELIX_UTILS_EXPORT __attribute__((visibility("default")))
# else
/* We are using this library */
# define CELIX_UTILS_EXPORT __attribute__((visibility("default")))
# endif
For both Linux and OSX the visibility attribute is always "default", so for Linux/OSX only 1 export header will also work.
Although I think generating 2 export headers for the OBJECT and SHARED libraries is more correct, I am not sure if we
should do this because it is more confusion.
Also note that only 1 export header will be installed (the SHARED export header).
This PR adds the generation and usage of an export header and its macros to the libraries etcdlib, dfi, utils and framework. For the updated libraries the default (C) symbol visibility is also set to hidden. As result almost all headers for the libraries etcdlib, dfi, utils and framework are updated to ensure the correct symbol visibility.
This is the first step for the issue #442.
The export headers are generated using the CMake function
generate_export_header
and for dfi, utils and framework the header filename is configured ascelix_<lib>_export.h
and the base macro name asCELIX_<LIB>
.The utils and framework libraries also have an
OBJECT
library variant (needed for error injection). For now I updated the CMakelists.txt file to configure theSHARED
/OBJECT
libs in 2 different ways:OBJECT
library and having theSHARED
library depending (link PUBLIC) on the _obj library.OBJECT
andSHARED
libraries and generating a export header for both library (with the same filename and macro names).The different ways can be toggled using the CMake variables
CELIX_UTILS_CMAKE_CONFIGURE_ALT_OPTION
andCELIX_FRAMEWORK_CMAKE_CONFIGURE_ALT_OPTION
, but before merging the PR I would like to choice one way and remove the other.The reason I added an other way of configuring the
SHARED
andOBJECT
library for utils and framework is that the generated export header use a#ifdef
to distinguish against building and using a library and IMO to let this work as intended both theOBJECT
andSHARED
library should have their own export header.See the following snippets from the utils and utils_obj generated export header:
For both Linux and OSX the visibility attribute is always "default", so for Linux/OSX only 1 export header will also work.
Although I think generating 2 export headers for the
OBJECT
andSHARED
libraries is more correct, I am not sure if we should do this because it is more confusion. Also note that only 1 export header will be installed (theSHARED
export header).