High Performance OPC UA Server SDK  1.7.0.367
SDK Build Environment

Table of Contents

Introduction

The High Performance OPC UA SDK uses CMake to build for various targets using different compilers and operating systems. This way we avoid maintaining dozens of proprietary IDE projects or writing custom Makefiles.

CMake is able to generate Makefiles, Ninja files and different IDE projects like e.g. Visual Studio, Eclipse and others.

Most IDEs like QtCreator, KDevelop, CLion, and others directly support CMake, for others CMake is able to generate IDE projects (e.g. Visual Studio). Since VS 2017 also Visual Studio has minimal support for CMake.

All IDEs that can deal with Makefiles or Ninja files (e.g. Vim and Emacs) can also be used with the CMake generated Makefiles. By default, we build using CMake+Ninja+CCache in our CI system which gives the best performance.

Creating Projects without CMake

When creating your own OPC UA applications you can also use CMake, but this is not required. Only the SDK must be built using our CMake files, your project can simply use the generated header files and libraries as usual.

After building the SDK you find all headers in CMAKE_INSTALL_PREFIX/include and all libraries in CMAKE_INSTALL_PREFIX/lib. Note that debug builds have d suffix, and release builds have not. This way you can have both variants side by side in the same folder.

Creating Projects with CMake

This is the simplest approach that is used also by also examples delivered with the SDK. To set up the application easily you need to include our sdk.cmake file. This sets up all search paths automatically. A basic application would look like this.

project(yourapp C)
cmake_minimum_required(VERSION 3.0)
# include sdk.cmake delivered with the SDK
# the environment variable SDKDIR should point to the SDK root directory
include($ENV{SDKDIR}/sdk.cmake)
# create list of sources to be built
set(SOURCES ...)
set(HEADERS ...)
# create executable
add_executable(${PROJECT_NAME} ${SOURCES} ${HEADERS} ${SDK_BSP_SRCS} ${SDK_ASM_SRCS})
# specify libraries to link
target_link_libraries(${PROJECT_NAME}
yourlibs
${SDK_SERVER_LIBRARIES}
${SDK_BASE_LIBRARIES}
${OS_LIBS} ${SDK_SYSTEM_LIBS}
)

All the SDK_* variables and OS_LIBS are provided by sdk.cmake, which makes setting up applications very easy. One of the problems when not using sdk.cmake is that the list of required libraries depend on the SDK configuration.

ConfigureCompiler.cmake

The SDK uses the file ConfigureCompiler.cmake, which gets included by sdk.cmake. This sets up high warning levels for all supported compilers and offers different options.

This is an incomplete list of possible options:

  • Treat Warnings as Errors
  • Enable Address Sanitizer
  • Enable Thread Sanitizer
  • Enabled Coverage Analysis
  • Enable Profiling
  • Enable Position Independent Code

The CMake options are named ENABLE_<COMPILER>_<NAME> e.g. ENABLE_GCC_ADDRESS_SANITZIER or ENABLE_CLANG_PIC, where COMPILER could be one of GCC, CLANG, or MSVC. Note that many options are only supported by GCC and Clang and not by MSVC. You can use the CMake GUI to find those options.

Position Independent Code

By default, CMake only enables position independent code (-fPIC) when building shared libraries. However, our ConfigureCompiler.cmake enables this also for static libraries, because some customers want to link these libraries to their shared libraries. This avoids unnecessary support cases. For normal applications like in our examples this does not hurt.

But if you link SDK libraries to applications that are not built using CMake and our ConfigureCompiler.cmake file, e.g. when integrating UA into legacy applications, this might cause issues, because your application is built without -fPIC. This normally leads to linker errors. In this case you can use the CMake option ENABLE_<COMPILER>_PIC=off to turn off position independent code.

References