open62541-compat

Adapts open62541 API to UA Toolkit API for usage in (1)Quasar-based projects, (2) independent UASDK-based projects

For bugs or suggestions please file a GitHub ticket.

Versions

Branch/Version	open62541 version included	LogIt version	Years active	Description
1.4.x	1.2.x	v0.1.1	2021-	Stable, widely used.
1.3.x	1.1.x	v0.1.1	2020-2021	Old-stable.
1.2.x	1.0.x	v0.1.1	2019-2020	Historic. Uses open62541 1.0.
1.1	0.3(-rc2)	v0.1.1	2018-2019	Historic. Uses open62541 0.3.
1.0	0.2 rc2	"master"	2018	Prehistoric. Significantly improved CMake scripting etc. Usable in Yocto and PetaLinux.
0.9	0.2 rc2	"master"	2015-2018	Prehistoric. Will stay cmake2.8 compatible. OK for native Linux and Win. Not useful for Yocto or PetaLinux.

Quick-start guide in Quasar

The procedure is documented in Quasar project. In Quasar repo, read:

Documentation/AlternativeBackends.html

Quick-start guide to get an stand-alone(independent) library

1. clone the repo

2. generate the makefiles / VS solution using cmake. A few options here, depending on

   (a) do you want to build open62541-compat as a shared or static library?

   (b) open62541-compat requires the boost library, do you want to use the system boost library or do you have a custom boost build?

   (c) open62541-compat depends on the quasar module LogIt, should the compat module clone, build and link LogIt source directly into the compat library or should the compat library consume LogIt from some external build.

   Time for an example...

Linux examples

• Build open62541-compat as a static library on linux. Use whatever the system installation of boost-devel is and build LogIt directly into the compat library

  cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_standard_install_cc7.cmake -DSTANDALONE_BUILD=ON
  

• Build open62541-compat as a shared library on linux (and boost/LogIt treated as above) - just add STANDALONE_BUILD_SHARED

  cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_standard_install_cc7.cmake -DSTANDALONE_BUILD=ON -DSTANDALONE_BUILD_SHARED=ON
  

• Build open62541-compat as a shared library on linux but with the LogIt library pulled in from some external build location (here LogIt is consumed as a shared library from /tmp/LogIt/). Note the -DLOGIT options define how LogIt is built into open62541-compat.

  cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_standard_install_cc7.cmake -DSTANDALONE_BUILD=ON -DSTANDALONE_BUILD_SHARED=ON -DLOGIT_BUILD_OPTION=LOGIT_AS_EXT_SHARED -DLOGIT_EXT_LIB_DIR=/tmp/LogIt/ -DLOGIT_INCLUDE_DIR=/tmp/LogIt/include/
  

Windows examples (using a mingw 'git bash' command prompt)

• Build open62541-compat as a static library on windows (visual studio 2017). Use a custom boost build (perhaps you built boost yourself, or have several boost installations available to choose from). Build LogIt directly into the compat library.

  # (comment) - set environment variables to point to the custom boost headers/libs directories (required by the toolchain file)
  export BOOST_PATH_HEADERS=/c/3rdPartySoftware/boost_mapped_namespace_builder/work/MAPPED_NAMESPACE_INSTALL/include/
  export BOOST_PATH_LIBS=/c/3rdPartySoftware/boost_mapped_namespace_builder/work/MAPPED_NAMESPACE_INSTALL/lib/
  
  cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_custom_win_VS2017.cmake -DSTANDALONE_BUILD=ON -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release
  

  Note! Your boost build/installation may be more exotic than ours, take a look at the sample custom toolchain file (boost_custom_win_VS2017.cmake) for inspiration, write your own and use it in your build via the build option OPEN62541-COMPAT_BUILD_CONFIG_FILE

• Build open62541-compat as a shared library on windows (visual studio 2017). Use a custom boost build. Use the LogIt library (here as a shared library) from some external build (as with the linux build above, the -DLOGIT options define how LogIt is built into open62541-compat).

  # (comment) - set environment variables to point to the custom boost headers/libs directories (required by the toolchain file)
  export BOOST_PATH_HEADERS=/c/3rdPartySoftware/boost_mapped_namespace_builder/work/MAPPED_NAMESPACE_INSTALL/include/
  export BOOST_PATH_LIBS=/c/3rdPartySoftware/boost_mapped_namespace_builder/work/MAPPED_NAMESPACE_INSTALL/lib/
  
  cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_custom_win_VS2017.cmake -DSTANDALONE_BUILD=ON -DSTANDALONE_BUILD_SHARED=ON -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release -DLOGIT_BUILD_OPTION=LOGIT_AS_EXT_SHARED -DLOGIT_EXT_LIB_DIR=/c/workspace/OPC-UA/LogIt/Release/ -DLOGIT_INCLUDE_DIR=/c/workspace/OPC-UA/LogIt/include/
  

Unit tests

Writing unit tests (and running unit tests) is a good habit; developers - if you're adding new features we recommend adding tests to really lock that work in place. Passing tests signify that features work now and provide an invaluable tool for future developers; to help them avoid inadvertently broken existing functionality. So, be a conscientious developer, write tests and run tests. By default (for stand-alone open62541-compat builds) unit tests are part of the build, if you need to skip them you can (but why would you?), more on skipping tests later. The open62541-compat module unit tests are based on the googletest framework. Note that the unit tests build to a stand-alone executable, this executable links to the stand-alone open62541-compat library as used in end-user applications - building the unit tests has ZERO effect on the actual end-user library binary that the build outputs.

• Unit tests and their requirements (basically googletest) are in the test subdirectory.
• New unit tests should be added to test/src (for help on writing tests see the googletest documentation, you might find inspiration in the existing tests too).
• From a clean start, the googletest framework is built from source (cloned from here), so it should execute on your platform.
• On running make for the open62541-compat module, the unit tests build to this executable: test/open62541-compat-Test. Note that executable is built after the open62541-compat library is built.
• Run those tests by simply invoking that executable:

./test/open62541-compat-Test

Skipping tests

If, for some reason, you feel you must omit unit tests from the build then there is a way, just add -DSKIP_TESTS=ON to your cmake invocation command line. Taking the example of the stand-alone static library build on linux above the command line would be

cmake -DOPEN62541-COMPAT_BUILD_CONFIG_FILE=boost_standard_install_cc7.cmake -DSTANDALONE_BUILD=ON -DSKIP_TESTS=ON

(and feel guilty.)

How do you use it in your independent UASDK server or client?

The include directory contains UASDK-(partially)-compatible headers, and you should link with the following libs:

• build/libopen62541-compat.a
• open62541/build/libopen62541.a

For questions/issues: file a ticket or write to [email protected]

CI build info	CI build status
linux (travis-ci)
windows (appveyor)