Issues with the installation process

[glubii]

Thanks for the nice library! Me and some of my colleagues tried to install pygafro for learning about CGA for robotics and some of us ran into some issues when using it. Due to the mix of operating systems we are using it took a while to figure most things out, but here is what we encountered so far:

• Missing cd pygafro after the git clone step
• CMakeFiles using the deprecated way of finding python did not work for everyone despite SET CMP0148 OLD. Replacing the lines with the FindPython(3) packages seemed to solved those issues.
• Related to that: The hardcoded path in the CMakeLists.txt (site-packages/lib/pythonX.yz/dist-packages/) causes issues on some systems. The dist-package subfolder seems to be only used on debian-based systems. This should be fixable to work architecture-independent by using the Python3_SITEARCH variable from the cmake package above. At least on my test systems it appeared to work fine that way.
• On some systems the build process fails during the unit tests. Debugging this on an up to date arch linux setup with the faulthandler package shows that it occurs when initializing MultiVectors:

Fatal Python error: Segmentation fault
Current thread 0x00007fec55175b80 (most recent call first):
File "/home/<username>/gafro/pygafro/build/src/pygafro/multivector.py", line 291 in _createTemplatedMultivector
File "/home/<username>/gafro/pygafro/build/src/pygafro/multivector.py", line 212 in create
File "/home/<username>/gafro/pygafro/build/src/pygafro/multivector.py", line 341 in _addMultivectors
File "/home/<username>/gafro/pygafro/tests/algebra/test_circle.py", line 119 in test_addition
File "/usr/lib/python3.12/unittest/case.py", line 589 in _callTestMethod
File "/usr/lib/python3.12/unittest/case.py", line 634 in run
File "/usr/lib/python3.12/unittest/case.py", line 690 in __call__
File "/usr/lib/python3.12/unittest/suite.py", line 122 in run
File "/usr/lib/python3.12/unittest/suite.py", line 84 in __call__
File "/usr/lib/python3.12/unittest/suite.py", line 122 in run
File "/usr/lib/python3.12/unittest/suite.py", line 84 in __call__
File "/usr/lib/python3.12/unittest/suite.py", line 122 in run
File "/usr/lib/python3.12/unittest/suite.py", line 84 in __call__
File "/usr/lib/python3.12/unittest/runner.py", line 240 in run
File "/home/<username>/gafro/pygafro/tests/main.py", line 27 in <module>
Extension modules: numpy._core._multiarray_umath, numpy.linalg._umath_linalg (total: 2)
zsh: segmentation fault (core dumped)

If there isn't a reason not to use the modern python cmake package I would create a pull request sometime this week after some further testing. Also I'm currently trying to reproduce the segmentation fault issue in a fresh docker container and would post this in a separate issue once it is ready.

[Kanma]

Hello

Following your issue , I remembered that we had a new version internally supporting building with ROS2, and thought that it might be a good idea to push it before you try to make changes.

Now the tests are failing on Github with a segmentation fault too, I'll try to fix that.

[glubii]

After playing around on different computer and docker containers I wasn't able to figure out what makes it break on some setups and not break on others. I suppose it depends on some differences in library versions provided by different linux distributions, but so far no luck.

With the newest commits it still installs the files into the wrong directory on non-debian based systems. With the following change it seems to install the files to the right folders depending on the distro-specific locations; at least when I tested it on ubuntu, debian, arch and fedora. I am unsure if that might break anything with the ROS2 things further down below though

[...]
SET(PYTHON_MODULE_EXTENSION ".so")

set(PYTHON_SITE_PACKAGES_INSTALL_DIR "${Python_SITEARCH}") # When using find_package(Python ..
set(PYTHON_SITE_PACKAGES_INSTALL_DIR "${Python3_SITEARCH}") # When using find_package(Python3 ..

if(DEFINED ENV{VIRTUAL_ENV})
[...]

small update: The segmentation faults seem to always occur when creating a MultiVector with arguments, independently from the number of arguments and if the combination of vectors should be precompiled or not