Feature reqeust: a Yocto meta layer of ecal

[fei4xu]

Is your feature request related to a problem? Please describe.
I'd like to include ecal in my Yocto project, so I need to create my own recipe for it.
During the process, there was several issues fixed in dirty ways, might not be the best way to do it.

Describe the solution you'd like
A officail maintained yocto recipe for ecal

Additional context
Currently I'm using Yocto 3.1, dunfell, on Ubuntu 18 as the host PC.

[FlorianReimold]

Hi fei4xu,

At the moment, from our side there is not really the use-case for yocto and thus we lack the know-how on how to write a recipe for it. Thus I doubt that we will have an officially maintained yocto recipe for ecal in the forseeable future.
However I think it would be a great start if you could post your yocto recipe and tell us about the changes you had to make. This may help others looking for this topic and may even provide a starting point for us, just in case we ever decide to officially maintain a yocto recipe.

[Kerstin-Keller]

Hi @fei4xu,

I agree with Florian Reimold, we currently do not have the "need" to provide yocto recipes.
However, if you let us know, where you had to make modifications, we'll gladly see how we might adapt (mainly our build files I guess), to make your experience better.
As for the recipe: In this repository, most dependencies are provided as submodules, but the usage of every one of them can be configured dependency by dependency. Hence I recommend to use submodules only for dependencies, where no Yocto recipe exists, and for all others fall back to their yocto counterpart.
You can trigger whether to include a dependcy as a submodule or take it from outside by passing appropriate CMake variables ECAL_THIRDPARTY_BUILD_***=ON/OFF, where *** is the name of the dependency.
Make sure, for Protobuf, to both depend on protobuf and the native version, due to the availability of protoc: DEPENDS += "protobuf protobuf-native

[fei4xu]

@Kerstin-Keller Since you mentioned ECAL_THIRDPARTY_BUILD_***=ON/OFF things, I'd like to ask what settings of ECAL_THIRDPARTY_BUILD_***=ON/OFF are used when building the arm64 PPA file? the default setting in cmake? All of them are ON by default (https://continental.github.io/ecal/development/ecal_cmake_options.html). Or as in the sample cmd in https://continental.github.io/ecal/development/building_ecal_from_source.html#fa-ubuntu-ubuntu-16-18-20-build

In my yocto eCAL is built from source, but I'd like it to be compatible to the installed PPA versions for thirdparty like protobuf, hdf5, and spdlog.

[Kerstin-Keller]

@FlorianReimold Do you know regarding the ppa?
The debians which you can download from the releases, you can see the build scripts for the github actions:
https://github.com/continental/ecal/blob/master/.github/workflows/build-ubuntu-18.yml
In general, the rule of thumb we applied is to use system packages, whereever available. When there are no system packages, the submodules are used.
protobuf and hdf5 use the system packages for sure, for spdlog I am not certain, I think it's a (statically linked) submodule.

[FlorianReimold]

The PPA eCAL 5.8.7 is built with the following settings:
dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release -DECAL_THIRDPARTY_BUILD_PROTOBUF=OFF -DECAL_THIRDPARTY_BUILD_GTEST=OFF -DECAL_THIRDPARTY_BUILD_CURL=OFF -DECAL_THIRDPARTY_BUILD_HDF5=OFF -DBUILD_PY_BINDING=ON

This basically uses the versions provided by Canonical whenever possible. Keep in mind that dh_auto_configure adds some more cmake settings automatically to provide a better debian experience, e.g. it will install the libraries to the modern arch directory.

This is taken from an ARM64 build log:
cd _build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_AUTOGEN_VERBOSE=ON -DCMAKE_INSTALL_LIBDIR=lib/aarch64-linux-gnu -DCMAKE_BUILD_TYPE=Release -DECAL_THIRDPARTY_BUILD_PROTOBUF=OFF -DECAL_THIRDPARTY_BUILD_GTEST=OFF -DECAL_THIRDPARTY_BUILD_CURL=OFF -DECAL_THIRDPARTY_BUILD_HDF5=OFF -DBUILD_PY_BINDING=ON ..

[fei4xu]

Hi, thanks for all the support here.

I'd like to share my yocto eCal patch here, just one for simpleini .cmake file:

diff --git a/cmake/Modules/Findsimpleini.cmake b/cmake/Modules/Findsimpleini.cmake
index 453d5098..9853c820 100644
--- a/cmake/Modules/Findsimpleini.cmake
+++ b/cmake/Modules/Findsimpleini.cmake
@@ -4,6 +4,7 @@ find_path(simpleini_INCLUDE_DIR
     include
     ${CONAN_SIMPLEINI_ROOT}/include
     ${CMAKE_SOURCE_DIR}/thirdparty/simpleini
+  NO_CMAKE_FIND_ROOT_PATH
   )
 
 if(simpleini_INCLUDE_DIR-NOTFOUND)

I'm not a cmake expert but some search online led me to NO_CMAKE_FIND_ROOT_PATH and it fixed my yotco build.

[fei4xu]

the NO_CMAKE_FIND_ROOT_PATH is also mentioned in #256

[christopherbate]

@fei4xu can you share your recipe? How are you handling HDF5 dependency? Are you pulling down the precompiled debs to install in your system root? In the cross compilation example that was just merged, only HDF5 and OpenSSL are assumed to be installed in the system root, the other items are built as part of the CMake project.

[fei4xu]

@christopherbate Yes, I'd love to see people working on Yocto with eCAL.

# https://continental.github.io/ecal/development/ecal_cmake_options.html
EXTRA_OECMAKE="-DCMAKE_BUILD_TYPE=Release \
  -DHAS_QT5=OFF \
  -DBUILD_SAMPLES=ON \
  -DBUILD_PY_BINDING=OFF \
  -DECAL_INCLUDE_PY_SAMPLES=OFF \
  -DECAL_THIRDPARTY_BUILD_PROTOBUF=OFF \
  -DECAL_THIRDPARTY_BUILD_GTEST=OFF \
  -DECAL_THIRDPARTY_BUILD_SPDLOG=ON \
  -DECAL_THIRDPARTY_BUILD_TINYXML2=ON \
  -DECAL_THIRDPARTY_BUILD_TERMCOLOR=ON \
  -DECAL_THIRDPARTY_BUILD_FINEFTP=ON \
  -DECAL_THIRDPARTY_BUILD_CURL=OFF \
  -DECAL_THIRDPARTY_BUILD_HDF5=OFF \
  -DCPACK_PACK_WITH_INNOSETUP=OFF \
  "

You can see that hdf5 is build externally by yocto, as suggested earlier.

DEPENDS += " zlib protobuf protobuf-native curl asio tclap hdf5 hdf5-native"
# by `DEPENDS += hdf5-native`, h5diff is polulated into "${WORKDIR}/recipe-sysroot-native"
# Copy from ${WORKDIR}/recipe-sysroot-native to ${WORKDIR}/recipe-sysroot to make hdf5's cmake happy, so ecal's cmake is happy
do_configure_prepend() {
  cp ${WORKDIR}/recipe-sysroot-native/usr/bin/h5* ${WORKDIR}/recipe-sysroot/usr/bin/
  cp ${WORKDIR}/recipe-sysroot-native/usr/bin/*h5 ${WORKDIR}/recipe-sysroot/usr/bin/
}

You can also see my hack of hdf5 above which I'm not very sure but it worked in my environment. I also raised the question on https://stackoverflow.com/a/66881677/10838321, but here is the warning: my solution was downvoted.