Integration of 3rd party libraries into FESA

To integrate 3rd party libraries into FESA the following should be considered:

The FESA3 installation @GSI is using RPMs. This allows to define versioned dependencies to other RPM packages for other libraries. During updates and (de-)installation 3rd party packages may be updated / uninstalled automatically by the RPM system. Therefore providing 3rd party libraries as RPM packages is the preferred way once the library is considered stable. As long as the library is not considered stable and still under development it may be located in a different location, e.g. /common/usr/fesa/saftlib-20.07.2017 .

All 3rd party libraries should follow a similiar structure

Structure	Content
<installation location>/3rd-party-library/<version>/lib/x86_64	static binary
<installation location>/3rd-party-library/<version>/include	header files

Versioning

To distinct between different versions of a library visible versioning is an advantage. This way libraries in different versions can be used simultaneously.

Integration into the FESA FWK

If 3rd party libraries are supposed to be included in the core part of FESA3 they should be static. This way no further action has to be taken to ship this library to a FEC along with FESA3 deploy-units.

3rd party libraries will be included in fesa-core-gsi's Makefile.dep (see DEPENDENT_COMPILER_OPTIONS etc. ).

Initialization routines from the 3rd party library should be added to the appropriate part of fesa-core-gsi if required, e.g. for adding the 3rd library to a deploy-unit's Makefile.dep or the specificInit initialization routine .

Integration into the FESA Code Generation

If routines from 3rd party libraries should be called from every deploy-unit such calls should be added to the code generation part of the FESA framework.

-- SolveighMatthies - 11 Oct 2017