summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--Makefile.am2
-rw-r--r--NEWS8
-rw-r--r--README307
-rw-r--r--doxygen.cfg12
-rw-r--r--src/CommonAPI/Runtime.cpp2
5 files changed, 166 insertions, 165 deletions
diff --git a/Makefile.am b/Makefile.am
index 6e787e9..d9d3e92 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,4 +96,4 @@ VariantTest_LDADD = ${LDADD} ${GTEST_LIBS} libCommonAPI.la
endif
doc: doxygen-doc
- asciidoc -b html -o doc/html/README.html README
+ asciidoc -a version=@PACKAGE_VERSION@ -b html -o doc/html/README.html README
diff --git a/NEWS b/NEWS
new file mode 100644
index 0000000..814294e
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,8 @@
+
+This is CommonAPI 2.1.6
+
+Changes since 2.1.5
+- Enhanced Windows Support
+- Fixed compile warnings
+- Fixed asciidoc errors
+- Move specification to CommonAPI-Tools
diff --git a/README b/README
index 406e07e..4a015f7 100644
--- a/README
+++ b/README
@@ -1,72 +1,77 @@
-GENIVI_CommonAPI
-================
+IPC CommonAPI C++
+-----------------
:Author: Juergen Gehring - juergen.gehring@bmw.de, Manfred Bathelt - manfred.bathelt@bmw.de
-:doctitle: GENIVI_CommonAPI
+:doctitle: IPC CommonAPI C++
+:version:
Copyright
----------
-Copyright (C) 2013, GENIVI Alliance, Inc.
-Copyright (C) 2013, BMW AG
-
-This file is part of GENIVI Project IPC Common API.
-
-Contributions are licensed to the GENIVI Alliance under one or more
-Contribution License Agreements or MPL 2.0 .
++++++++++
+Copyright (C) 2014, BMW AG.
+Copyright (C) 2014, GENIVI Alliance, Inc.
+This file is part of GENIVI Project IPC Common API C++.
-(C) Copyright
-This Source Code Form is subject to the terms of the
-Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with
-this file, You can obtain one at http://mozilla.org/MPL/2.0/.
-
-For further information see https://collab.genivi.org/wiki/display/genivi/SysInfraEGCommonIDLCommonAPIGuide
+Contributions are licensed to the GENIVI Alliance under one or more Contribution License Agreements or MPL 2.0.
-== License
-This project is licensed under MPL 2.0
+License
++++++++
+This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, you can obtain one at http://mozilla.org/MPL/2.0/.
-Contribution is done under GENIVI CLA or MPL2.0.
+Version
++++++++
+{version}
-== Version
-The current version can be taken from the git.
+Further information
++++++++++++++++++++
+Source code and latest news can be found at http://projects.genivi.org/commonapi/.
-== Common API Overview
+Common API Overview
+~~~~~~~~~~~~~~~~~~~
-Common API and its mechanism specific bindings (e.g. Common API D-Bus) provide a set of libraries and tools to work with
-RPC communication in a way independent of wich mechanism is used. It currently consists of four subprojects:
-----
-CommonAPI - This is the base C++ library, which provides the application interface for users and can
- load runtime bindings such as dbus. (This is the current package.)
-CommonAPI-Tools - The eclipse based tools for CommonAPI. This is essentially the code generator for
- Franca -> Common API C++ code.
-CommonAPI-D-Bus - This is the D-Bus binding C++ library, which provides the necesary code to communicate
- over D-Bus. This is invisible to the application code, and simply needs to be linked against.
-CommonAPI-D-Bus-Tools - The eclipse based tools for CommonAPI D-Bus. This is the code generator for
- Franca -> Common API D-Bus C++ code.
-----
-== Build Instructions
+Common API C++ and its mechanism specific bindings (e.g. Common API D-Bus) provide a set of libraries and tools to work with
+RPC communication in a way independent of which mechanism is used. It currently consists of four sub-projects:
+
+*CommonAPI* - This is the base C++ library, which provides the application interface for users and can load runtime bindings such as DBus.
+
+*CommonAPI-Tools* - The Eclipse based tools for CommonAPI. This is essentially the code generator for the generation of C++ code from Franca IDL.
-Use autotools to build this package:
+*CommonAPI-D-Bus* - This is the D-Bus binding C++ library, which provides the necessary code to communicate over D-Bus. This is invisible to the application code, and simply needs to be linked against.
+
+*CommonAPI-D-Bus-Tools* - The eclipse based tools for CommonAPI D-Bus. This is the code generator for Franca IDL to Common API D-Bus C++ code.
+
+Build Instructions
+~~~~~~~~~~~~~~~~~~
+
+Linux
++++++
+
+Use Autotools to build this package:
----
# autoreconf -i
# ./configure
# make
# sudo make install (or alternative install process, eg. checkinstall on debian-based distributions, such as Ubuntu)
----
-If the environment variable GTEST_CONFIG is set to the path of the gtest-config script in a Gtest tree test will also be built.
-To build the Windows version of CommonAPI with Visual Studio, you can use the solution file CommonAPI.sln. It is configured to build CommonAPI as a static library.
-To build the Tests project you have to set an environment variable called GTEST pointing to your gtest directory (e.g. C:\gtest-1.7.0), and if applicable restart your
-Visual Studio.
+If the environment variable +GTEST_CONFIG+ is set to the path of the gtest-config script in a Gtest tree test will also be built.
+
+Windows
++++++++
+
+To build the Windows version of CommonAPI with Visual Studio, you can use the solution file CommonAPI.sln. It is configured to build CommonAPI as a static library. To build the test project you have to set an environment variable called +GTEST+ pointing to your gtest directory (e.g. C:\gtest-1.7.0), and if applicable restart your Visual Studio.
+
Information for building of gtest:
-Download gtest from https://code.google.com/p/googletest/ e.g. gtest-1.7.0.zip
-Unpack the archiv into a directory
-Open the solution gtest-md.sln with Visual Studio 2013 and build gtest
-== Linking against CommonAPI
+- Download gtest from https://code.google.com/p/googletest/ e.g. gtest-1.7.0.zip
+- Unpack the archiv into a directory
+- Open the solution gtest-md.sln with Visual Studio 2013 and build gtest
+
+Linking
+~~~~~~~
+
+Against CommonAPI
++++++++++++++++++
-CommonAPI bindings requires successful activation of all static initialization code on library load. Therefore it is
-necessary to activate certain linker flags to ensure this is always the case. These should be specified in the
-pkg-config files of the respective bindings, but are also listed here. In case of dynamic linking (.so)
---no-as-needed must be specified:
+CommonAPI bindings require successful activation of all static initialization code on library load. Therefore it is necessary to activate certain linker flags to ensure this is always the case. These should be specified in the pkg-config files of the respective bindings, but are also listed here. In case of dynamic linking (.so) --no-as-needed must be specified:
----
-Wl,--no-as-needed -lbindingLib -Wl,--as-needed
----
@@ -76,72 +81,56 @@ In case of static linking --whole-archive must be specified:
-Wl,--whole-archive bindingLib.a -Wl,--no-whole-archive
----
-=== Linking generated proxies & stubs
+Generated Proxies and Stubs
++++++++++++++++++++++++++++
-Generated proxies and stubs also require successful activation of all static initialization code on load.
-If they are provided in either a static or dynamic library to the application they must also be linked wrapped in the
-flags described above.
+Generated proxies and stubs also require successful activation of all static initialization code on load. If they are provided in either a static or dynamic library to the application they must also be linked wrapped in the flags described above.
-== Elements marked as deprecated
+Deprecated Elements
++++++++++++++++++++
-All elements that are marked as deprecated on Common API level are considered to be redundant, and normally
-the other way of acchieving the same (the way pointed to by the marked elements) is the way we recommend to use.
-Elements marked as deprecated will be removed once we have reliable and comprehensive feedback telling us they
-are not used anymore by anybody, but they will remain in Common API for compatibility reasons at least until then.
+All elements that are marked as deprecated on CommonAPI level are considered to be redundant, and normally the other way of achieving the same (the way pointed to by the marked elements) is the way we recommend to use. Elements marked as deprecated will be removed once we have reliable and comprehensive feedback telling us they are not used anymore by anybody, but they will remain in Common API for compatibility reasons at least until then.
+Dynamic Loading of Middleware Bindings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-== Fully Dynamic loading of middleware bindings
-
-CommonAPI supports the loading of middleware specific libraries at runtime, without even linking them to the executable beforehand.
-For this purpose, each middleware binding library provides a short well known name that can be used to identify the library.
-If such a well known name is passed as an argument to _CommonAPI::Runtime::load()_, CommonAPI will try to dynamically resolve the
-given name (i.e. find an appropriate library for it), if it is not already provided by a library that was linked at compile time.
-In order to resolve a middleware specific library, the default search paths _/usr/lib_ and _/usr/local/lib/_ will be searched for
-all libraries that match the name pattern "libCommonAPI-<arbitraryName>.so[.major[.minor.revision]]". This naming constraint
-exists in order to prevent too many libraries to be opened and closed again, as each of the libraries found will be searched for the
-presence of the identifying well known name.
-If there are more libraries for the same binding, the library with the higher version will take precedence.
-The resolution procedure can be extended by providing an environment variable with additonal search paths (see below),
-or by specifying a specific path for a specific binding using configuration files (see below). +
-NOTE: If you call _CommonAPI::Runtime::load()_ without an parameter when no middleware library has been linked at compile time,
- CommonAPI will load the first middleware library it encounters on the default and specified search paths, regardless of
- its version.
+CommonAPI supports the loading of middleware specific libraries at runtime, without even linking them to the executable beforehand. For this purpose, each middleware binding library provides a short well known name that can be used to identify the library. If such a well known name is passed as an argument to _CommonAPI::Runtime::load()_, CommonAPI will try to dynamically resolve the given name (i.e. find an appropriate library for it), if it is not already provided by a library that was linked at compile time.
+In order to resolve a middleware specific library, the default search paths _/usr/lib_ and _/usr/local/lib/_ will be searched for all libraries that match the name pattern "libCommonAPI-<arbitraryName>.so[.major[.minor.revision]]". This naming constraint exists in order to prevent too many libraries to be opened and closed again, as each of the libraries found will be searched for the presence of the identifying well known name.
-== Configuring CommonAPI
+If there are more libraries for the same binding, the library with the higher version will take precedence.
+The resolution procedure can be extended by providing an environment variable with additional search paths (see below),
+or by specifying a specific path for a specific binding using configuration files (see below).
-It is possible to provide additional configuration parameters to tailor CommonAPI to your specific system architecture.
-This can be done either by providing configuration files or by setting appropriate environment variables.
+[NOTE]
+If you call _CommonAPI::Runtime::load()_ without an parameter when no middleware library has been linked at compile time, CommonAPI will load the first middleware library it encounters on the default and specified search paths, regardless of its version.
+Configuring CommonAPI
+~~~~~~~~~~~~~~~~~~~~~
-=== Configuration Files
+It is possible to provide additional configuration parameters to tailor CommonAPI to your specific system architecture. This can be done either by providing configuration files or by setting appropriate environment variables.
-Each CommonAPI configuration file will define additional parameters for specific categories.
-Which categories and which parameters for each of those categories are available will be detailed below.
+Configuration Files
++++++++++++++++++++
-All parameters for all categories are optional. For each omitted parameter a reasonable default will be set. Because of
-this, it is not mandatory to provide a config file unless you want to alter any of the configurable default values.
+Each CommonAPI configuration file will define additional parameters for specific categories. Which categories and which parameters for each of those categories are available will be detailed below. All parameters for all categories are optional. For each omitted parameter a reasonable default will be set. Because of this, it is not mandatory to provide a config file unless you want to alter any of the configurable default values.
-CommonAPI config files can be defined locally per binary, globally per binary or globally for all binaries.
-If more than one config file is defined for a given binary (e.g. one locally and one globally) and a given category
-is defined in several of these config files, for each parameter that may be provided for this category the value found
-in the most specific config file will take precedence. If a category is defined several times within the same config file,
+CommonAPI configuration files can be defined locally per binary, globally per binary or globally for all binaries. If more than one configuration file is defined for a given binary (e.g. one locally and one globally) and a given category is defined in several of these configuration files, for each parameter that may be provided for this category the value found in the most specific configuration file will take precedence. If a category is defined several times within the same configuration file,
the first occurrence of each parameter will take precedence.
All categories and all parameters are separated from each other by one or more newline characters.
-CommonAPI Config files have to be named this way:
+CommonAPI Configuration files have to be named this way:
----
# Binary local: "<FqnOfBinary>.conf", e.g. "/usr/bin/myBinary.conf" if the binary is "/usr/bin/myBinary"
# Binary global: "/etc/CommonApi/<NameOfBinary>.conf", e.g. "/etc/CommonAPI/myBinary.conf"
# Global: "/etc/CommonAPI/CommonAPI.conf"
----
-==== Available categories
+Available Categories:
.Well known names of specific middleware bindings
-Allows to set parameters that influence the loading procedure of specific middleware bindings.
-The syntax is:
+Allows to set parameters that influence the loading procedure of specific middleware bindings. The syntax is:
----
{binding:<well known binding name>}
@@ -151,76 +140,80 @@ genpath=<One or more fully qualified names to libraries containing additional (g
default
----
-* *libpath*: Provides a fully qualified name that replaces the search path when trying to dynamically load the identified binding.
- The library found at libpath will take precedence over all other dynamically discoverable libraries for this binding. +
- NOTE: If a library for the specified middleware binding is linked to the binary already, this parameter will have no effect. +
- WARNING: _Not_ finding an appropriate library at libpath is considered to be an error! In this case, no further attempts to resolve
- the library will be made. If you want to have an explicit error state, call the overloaded _Runtime::load()_
- functions and pass in an instance of _Runtime::LoadState_ as argument.
-* *alias*: In order to load a specific middleware binding, one normally has to know the well known name of the middleware
- (e.g. "DBus" for the D-Bus middleware binding) and pass this name as parameter when calling _CommonAPI::Runtime::load("<name>")_.
- _alias_ maps the well known name for this purpose to one or more arbitrary aliases, thereby decoupling the loading of a specific
- middleware binding from its specific name. +
- NOTE: You MAY specify this parameter more than once for a binding. The effect will be the same as if you had one alias parameter
- specifying the exact same names separated by ":". +
- NOTE: If the same alias is specified more than once, only the first occurrence of the alias will be considered. +
- WARNING: As CommonAPI itself does not know about which well known middleware names there are, it is possible to specify the well known
- name of an actual binding as an alias for any other middleware binding. In this case, the actual middleware binding will not
- be accessible any longer, unless you specify another unique alias for it.
-* *genpath*: Specifies one or more paths at which a generic library containing additional (e.g. generated middleware and interface specific)
- code for the middleware binding is to be found. This additional code will be injected when the specific middleware considers
- it to be the right time to do so. +
- NOTE: You MAY specify this parameter more than once for a binding. The effect will be the same as if you had one genpath parameter
- specifying the exact same values separated by ":". +
- NOTE: If _No_ such parameter is defined, the standard search paths "/usr/lib" and "/usr/local/lib" plus any additional paths defined in
- the environment variable COMMONAPI_BINDING_PATH (see below) will be searched for any libraries that match the name pattern
- "lib<wellKnownMiddlewareName>Gen-<arbitraryName>.so[.major[.minor.revision]]". All matching libraries will be loaded. +
- WARNING: _Not_ finding an appropriate library at any single one of the defined genpaths may result in undefined behavior. +
- NOTE FOR DEVELOPERS: The _genpath_ parameter will be parsed by the CommonAPI framework and stored in _CommonAPI::Configuration_. Actually loading the
- libraries and following the rules described here however is task of the specific middleware binding. You might want to use
- the convenience methods provided in <CommonAPI/utils.h> for this purpose. By taking control of the actual proceedings,
- you may introduce additional mechanisms of discovering and loading such libraries, and you can defer the loading of the
- libraries until you deem it to be the right time to do so.
-* *default*: Specifies the library for this binding as the default that is to be loaded if no parameter is given to _CommonAPI::Runtime::load()_. +
- WARNING: _Not_ finding an appropriate library for a configured default binding at neither specified nor the default paths is considered to be an error!
- In this case, no further attempts to find another default library will be made! If you want to have an explicit error state, call the
- overloaded _Runtime::load()_ functions and pass in an instance of _Runtime::LoadState_ as argument.
-
-
-=== Environment Variables
-
-* COMMONAPI_BINDING_PATH: By default, the standard paths "/usr/lib" and "/usr/local/lib" will be searched for binding libraries that are
- loaded dynamically (i.e. at runtime without linking them to the binary beforehand). All paths defined in this environment variable
- will take precedence over those two default paths. Separator between several paths is ":".
-
-
-== Remarks on Windows version
-
-Due to a compiler bug in Visual Studio 2013, which is not able to call constructors of variadic template packs, if they contain zero elements, the factory’s buildProxy method does not return a proxy without AttributeExtensions, but implicitly adds a WINDummyAttributeExtension. So to assign such a proxy use the auto keyword or the typedef ***ProxyDefault in the generated ***Proxy.h.
-This restriction does only affect the windows port. The typedef is cross platform compatible as it points to a proxy with empty template list on Linux.
-
-The Windows version does not support dynamic loading.
-
-== Working on the code & contribution
-
-.First get the code from the git:
- git clone
-
-.Get an overview of all branches:
- git branch
-
-.Switch to the branch you want to work on (master is the feature branch) and verify that it has switched (* changed)
- git checkout <your branch>
- git branch
-
-.Best practice is to create a local branch based on the current branch:
- git branch working_branch
+*libpath*
+
+Provides a fully qualified name that replaces the search path when trying to dynamically load the identified binding. The library found at +libpath+ will take precedence over all other dynamically discoverable libraries for this binding.
+
+[NOTE]
+If a library for the specified middleware binding is linked to the binary already, this parameter will have no effect. _Not_ finding an appropriate library at +libpath+ is considered to be an error! In this case, no further attempts to resolve the library will be made. If you want to have an explicit error state, call the overloaded _Runtime::load()_ functions and pass in an instance of _Runtime::LoadState_ as argument.
+
+*alias*
+
+In order to load a specific middleware binding, one normally has to know the well known name of the middleware (e.g. "DBus" for the D-Bus middleware binding) and pass this name as parameter when calling _CommonAPI::Runtime::load("<name>")_. _alias_ maps the well known name for this purpose to one or more arbitrary aliases, thereby decoupling the loading of a specific middleware binding from its specific name.
+
+[NOTE]
+You MAY specify this parameter more than once for a binding. The effect will be the same as if you had one alias parameter specifying the exact same names separated by ":". If the same alias is specified more than once, only the first occurrence of the alias will be considered. As CommonAPI itself does not know about which well known middleware names there are, it is possible to specify the well known name of an actual binding as an alias for any other middleware binding. In this case, the actual middleware binding will not be accessible any longer, unless you specify another unique alias for it.
+
+*genpath*
+
+Specifies one or more paths at which a generic library containing additional (e.g. generated middleware and interface specific) code for the middleware binding is to be found. This additional code will be injected when the specific middleware considers it to be the right time to do so.
+
+[NOTE]
+You MAY specify this parameter more than once for a binding. The effect will be the same as if you had one genpath parameter specifying the exact same values separated by ":". If _No_ such parameter is defined, the standard search paths "/usr/lib" and "/usr/local/lib" plus any additional paths defined in the environment variable COMMONAPI_BINDING_PATH (see below) will be searched for any libraries that match the name pattern "lib<wellKnownMiddlewareName>Gen-<arbitraryName>.so[.major[.minor.revision]]". All matching libraries will be loaded. _Not_ finding an appropriate library at any single one of the defined genpaths may result in undefined behavior.
+
+NOTE FOR DEVELOPERS:
+The _genpath_ parameter will be parsed by the CommonAPI framework and stored in _CommonAPI::Configuration_. Actually loading the libraries and following the rules described here however is task of the specific middleware binding. You might want to use the convenience methods provided in <CommonAPI/utils.h> for this purpose. By taking control of the actual proceedings, you may introduce additional mechanisms of discovering and loading such libraries, and you can defer the loading of the libraries until you deem it to be the right time to do so.
+
+*default*
+
+Specifies the library for this binding as the default that is to be loaded if no parameter is given to _CommonAPI::Runtime::load()_. _Not_ finding an appropriate library for a configured default binding at neither specified nor the default paths is considered to be an error! In this case, no further attempts to find another default library will be made! If you want to have an explicit error state, call the overloaded _Runtime::load()_ functions and pass in an instance of _Runtime::LoadState_ as argument.
+
+Environment Variables
++++++++++++++++++++++
+
+*COMMONAPI_BINDING_PATH*
+By default, the standard paths "/usr/lib" and "/usr/local/lib" will be searched for binding libraries that are loaded dynamically (i.e. at runtime without linking them to the binary beforehand). All paths defined in this environment variable will take precedence over those two default paths. Separator between several paths is ":".
+
+Remarks on Windows Version
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Restrictions
+++++++++++++
+
+- Due to a compiler bug in Visual Studio 2013, which is not able to call constructors of variadic template packs, if they contain zero elements, the factory’s buildProxy method does not return a proxy without AttributeExtensions, but implicitly adds a WINDummyAttributeExtension. So to assign such a proxy use the auto keyword or the typedef ***ProxyDefault in the generated ***Proxy.h. This restriction does only affect the windows port. The typedef is cross platform compatible as it points to a proxy with empty template list on Linux.
+- The Windows version does not support dynamic loading.
+
+Working on the code & contribution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- First get the code from the git:
+----
+git clone
+----
+
+- Get an overview of all branches:
+----
+git branch
+----
+
+- Switch to the branch you want to work on (master is the feature branch) and verify that it has switched (* changed)
+----
+git checkout <your branch>
+git branch
+----
+
+- Best practice is to create a local branch based on the current branch:
+----
+git branch working_branch
+----
Start working, best practice is to commit smaller, compilable pieces during the development process that makes it easier to handle later on.
-.If you want to commit you changes, send them to the author, you can create a patch like this:
- git format-patch working_branch <your branch>
+- If you want to commit you changes, send them to the author, you can create a patch like this:
+----
+git format-patch working_branch <your branch>
+----
This creates a set of patches that are published via the mailing list. The patches will be discussed and then merged & uploaded on the git by the maintainer.
-Patches can be accepted either under GENIVI Cla or MPL 2.0 (see section License). Please be sure that the signed-off-by is set correctly. For more, check out http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
+Patches can be accepted under MPL 2.0 (see section License). Please be sure that the signed-off-by is set correctly. For more, check out http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
diff --git a/doxygen.cfg b/doxygen.cfg
index bbae96b..bd426c3 100644
--- a/doxygen.cfg
+++ b/doxygen.cfg
@@ -398,35 +398,35 @@ EXTRACT_ANON_NSPACES = NO
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
-HIDE_UNDOC_MEMBERS = NO
+HIDE_UNDOC_MEMBERS = YES
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
-HIDE_UNDOC_CLASSES = NO
+HIDE_UNDOC_CLASSES = YES
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
-HIDE_FRIEND_COMPOUNDS = NO
+HIDE_FRIEND_COMPOUNDS = YES
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
-HIDE_IN_BODY_DOCS = NO
+HIDE_IN_BODY_DOCS = YES
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
-INTERNAL_DOCS = NO
+INTERNAL_DOCS = YES
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
@@ -440,7 +440,7 @@ CASE_SENSE_NAMES = YES
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
-HIDE_SCOPE_NAMES = NO
+HIDE_SCOPE_NAMES = YES
# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
# will put a list of the files that are included by a file in the documentation
diff --git a/src/CommonAPI/Runtime.cpp b/src/CommonAPI/Runtime.cpp
index 01b9d47..bc5c4dc 100644
--- a/src/CommonAPI/Runtime.cpp
+++ b/src/CommonAPI/Runtime.cpp
@@ -48,7 +48,7 @@ bool Runtime::tryLoadLibrary(const std::string& libraryPath,
//called, thereby causing memory corruptions. Therefore, we must be able to access the middlewareInfo
//of the newly dlopened library in order to determine whether it already has been linked.
*sharedLibraryHandle = dlopen(libraryPath.c_str(), RTLD_LAZY | RTLD_LOCAL | RTLD_DEEPBIND);
- if (sharedLibraryHandle == NULL) {
+ if (*sharedLibraryHandle == NULL) {
return false;
}