Automatically integrate open62541 library during building

[eddybl]

Situation

Right now the initial setup of the opc-ua module is not trivial and if people do not read carefully they also might install a non-compatible version of the open62541 library. Maybe we can offer a way to automatically integrate a pinned version of the open62541 library.

Our Solution

For our local build of our opc-ua module we are already doing that:

1. Define the open62541 library version (currently we use $EPICS_LIB_OPEN62541_VERSION=1.3.15)
2. Install cmake and curl
3. Download from https://github.com/open62541/open62541/archive/refs/tags/v$EPICS_LIB_OPEN62541_VERSION.tar.gz
4. Build open62541
5. In the CONFIG_SITE use the EMBED mode
6. Build opcua module

Building open62541

For building the open62541 module we use the following setup (temp_dir is the path we unpack the source open6254):

opcua_dir="$EPICS_INSTALL_DIR/modules/opcua-`get_component_version opcua`"
cmake \
    -S "$temp_dir" \
    -B "$temp_dir"/build \
    -DBUILD_SHARED_LIBS=OFF \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_INSTALL_PREFIX="$opcua_dir"/devOpcuaSup/open62541/lib-open62541 \
    -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=OFF \
    -DOPEN62541_VERSION="v`$EPICS_LIB_OPEN62541_VERSION`" \
    -DUA_ENABLE_ENCRYPTION=OPENSSL
make -C "$temp_dir"/build
make -C "$temp_dir"/build install
rm -rf "$temp_dir"

CONFIG_SITE.local configuration

OPEN62541 = $(TOP)/devOpcuaSup/open62541/lib-open62541
OPEN62541_DEPLOY_MODE = EMBED
OPEN62541_USE_CRYPTO = YES

USR_CXXFLAGS += -std=c++11

ToDos for Upstream Implementation

• Define a variable for the upstream open62541 version to use
• Define an optional (or default) flag which would trigger the auto-integration
• Adjust the build scripts to install curl and cmake
• Execute download and building the open62541 lib

To reduce build complexity we could:

• Expect curl and cmake to be present
• Expect the proper sources of open62541 to be there already (but we would lose the version pinning)

Maybe the easiest thing would also just be an additonal script, which people could run if they want to, which would do all of the above, which wouldn't require changes to just building the module

References

You can have a look at our build script here: https://gitlab.kit.edu/kit/ibpt/controls/epics/distribution/epics-build-tool/-/blob/6901d88980504f9808b9a3f7f533a6f41f0ca595/shlib/build_lib_open62541.sh

[ralphlange]

Hm.
That does the static + EMBED build - I didn't expect that to be the most common case, but I could be convinced that it should be.

[ralphlange]

Maybe the easiest thing would also just be an additonal script, which people could run if they want to, which would do all of the above, which wouldn't require changes to just building the module.

I like that, as it offers an easy-peasy way to get things working (static + EMBED would be perfectly appropriate) and still allows anyone to do their own separate build/packaging/whatever of open62541 if they prefer.

[eddybl]

Well we tried building .deb system packages, but it required some patching to get this working (based on the debian scripts provided by the library itself), so this kind of made everything more complicated.

Using a non-static non-embeded build might be useful if there is another use-case for the library, but as long as it is just for the EPICS opc-ua module, I think this is fine.