A problem: Path pollution occurs when cross-compiling the ROS 2 message package

[ctgulzh]

Hello everyone!
I recently used the petalinux2022.2 tool on an X86 host to cross-compile a custom ROS 2 message package for integration into a boot image for an embedded device (Xilinx MPSoC device) built using petalinux2022.2.
I'm currently encountering a cross-compilation error with the following error message:
CMake Error in CMakeLists.txt: | Target "mnist_cnn_interface__rosidl_generator_py" | INTERFACE_INCLUDE_DIRECTORIES property contains path: | "/home/lzh/lzh/petalinux/kr260_xsa_ros/build/tmp/work/cortexa72-cortexa53-xilinx-linux/mnist-cnn-interface/0.1.0-r0/recipe-sysroot-native/usr/lib/python3.9/site-packages/numpy/core/include" | | which is prefixed in the source directory.
My initial analysis suggests a path contamination issue. The rosidl_generate_interfaces metapackage uses the NumPy library in the host development environment's Python path when generating the Python interface language from the message package source code (the rosidl_generate_interfaces metapackage is designed for compiling message packages on the host). Instead of using the NumPy library in the embedded device boot image in the path /petalinux/kr260_xsa_ros/build/tmp/work/cortexa72-cortexa53-xilinx-linux/mnist-cnn-interface/0.1.0-r0/recipe-sysroot/usr/include/python3.9, it actually should.
Is my suspicion correct? If so, how can I resolve this Python path contamination issue during cross-compilation?
Attached is the full error message. I look forward to your response!
cmake-error.txt

[ctgulzh]

Here's my development setup:
x86 host system: Ubuntu 18.04
ROS 2 version: humble
PetaLinux software version: petalinux 2022.2 (corresponding to the Yocto version: honister)

[robwoolley]

Thanks for reporting the issue. Honister went end-of-life in 2022. I am happy to try to help but I may be limited in what I can reproduce on this end.

It looks like you are trying to build the mnist-cnn-interface recipe. It seems that the CMakeLists.txt for that package has a target named "mnist_cnn_interface__rosidl_generator_py" that tries to use the include directory for Numpy.

The approach I usually use it to try to use CMake targets (eg. Python::NumPy) wherever possible to avoid absolute buildpaths from sneaking into the generate CMake files. If you add the CMake target to the target_link_libraries line, you also don't need to specify the include dirs (eg. ${Python_NumPy_INCLUDE_DIRS}) explicitly as they get included automatically.

Hope that helps. Please point me to your mnist-cnn-interface-recipe and the associated CMakeLists.txt if you need any extra direction so I can point you in the right direction.

[ctgulzh]

Thank you for your reply. I will provide the recipes file, CMakeList.txt file and package.xml file of the ROS 2 message package.
mnist-cnn-interface_0.1.0.bb.txt
CMakeLists.txt
package-xml.txt
I noticed you mentioned that the package's CMakeLists.txt file appears to contain a target named mnist_cnn_interface__rosidl_generator_py . The issue should actually be with the following CMakeLists.txt statement:

find_package(rosidl_default_generators REQUIRED)

rosidl_generate_interfaces(${PROJECT_NAME}
"FpgaIn.msg"
"FpgaOut.msg"
"Test.msg"
)

My guess is that the rosidl_default_generators module, a built-in low-level message interface generator for ROS 2, builds the corresponding low-level C/C++/Python message interface based on the message source code, regardless of whether the message package is generated using the ament_cmake or ament_python type. This behavior, coupled with the incorrect reading of libraries from the host Python path during the CMake compilation process, ultimately leads to CMake compilation errors.

Assuming my guess is correct. To resolve the issue, I first tried adding the directives set(ROSIDL_GENERATOR_PY FALSE) and set(ROSIDL_GENERATOR_CPP TRUE) to CMakeLists.txt to disable the default underlying Python interface generation behavior of the rosidl_default_generators function module, but the same problem persisted.
Since I cannot disable the default underlying Python interface generation behavior of the rosidl_default_generators function module, I will investigate the Python environment variable settings during cross-compilation of the ROS 2 message package on the X86 host to see if the issue is caused by incorrect pre-setting of Python environment variables. This suspicion stems from the fact that the ROS 2 message package cross-compilation using the petalinux tool reads some default configurations provided by Xilinx. Regarding your suggestion of setting variables directly in the CMakeLists.txt file to specify the required Python libraries for compilation, I will also consider the feasibility.
Thanks for your reply, and I look forward to further communication!