eclipse / upm

UPM is a high level repository that provides software drivers for a wide variety of commonly used sensors and actuators. These software drivers interact with the underlying hardware platform through calls to MRAA APIs.
MIT License
663 stars 412 forks source link

Cannot import modules on raspberry Pi buster compiled with cmake3.13+ and swig4.00 (partial solution and workaround) #682

Closed g-vidal closed 1 year ago

g-vidal commented 5 years ago

I am using mraa upm on a raspberryPi debian buster. mraa and upm are compiled with swig4.00 and cmake 3.13.4. With the master some problems occur due to the absence of value for CMP0078. The solution found is to add the following code in CMakelists.txt :

if (CMAKE_VERSION VERSION_GREATER "3.13")
  cmake_policy(SET CMP0078 OLD)
endif ()

In mraa value NEW is also valid but not here for upm !!! I suppose that some work is needed to enable that value.

Once this problem has been solved the cmake process and compilation go smoothly but modules from the package upm cannot be imported. The reason is that none of the pyupm_XXXXX.py are copied in the /usr/lib/python3.7/dist-packages/upm/ and/usr/lib/python2.7/dist-packages/upm/ folders. Doing that by hand solves partly the problem because python interfaces files from path_to/upm/build/interfaces/pythonx.y/ are also missing. After copying them I am back to normal operations.... I can make a pull request for the first cmake solution if it is acceptable but I have no idea on the proper changes to make for the second issue.

Let me know if I can help testing commits to solve this. Thanks for your work.

Propanu commented 5 years ago

There are a few occurrences of ${SWIG_MODULE_${name}_REAL_NAME} in our CMake files that would need to be updated to the for the new policy. My understanding is that this works with older versions too but now with 3.13 the default behavior changed. I will have to check how far back this goes with CMake to properly set version guards.

On the other issue, the Python modules should install correctly if you build the entire UPM project, is this the situation you're in? When building individual modules (from build/src/mymodule) the manual steps are normal behavior. The project variable MODULE_LIST should be used instead as it handles the dependencies too.

g-vidal commented 5 years ago

Thanks @Propanu for the quick answer and the will to further investigate, I fear that this is beyond my competencies and I think that unfortunately I cannot help. For the second question I am doing a full compilation that used to work properly. I do not change anything I have purged everything linked with upm and done a git clone more than once; the result is always the same. I am wondering if the problem could occur because of the use in debian of the dist-packages folder instead of the site-packages. But I have no raspberryPI at hand this week to make tests. Let me know if you want me to test some configs or compilations.