Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installed eigenpyConfig.cmake finds a different python executable version #413

Open
jmirabel opened this issue Dec 4, 2023 · 8 comments

Comments

@jmirabel
Copy link
Contributor

jmirabel commented Dec 4, 2023

If I am not wrong, the version of the Python executable is not export and only the boost component (e.g. python38) contains some version information.

When installing it as a binary package from robotpkg, we hit a case where the python executable found by eigenpyConfig.cmake is Python 2.7 while we installed robotpkg-py38-eigenpy.

Shouldn't the version of the Python executable be stored in the Eigenpy cmake config file and used to find the correct python executable?

I know I can bypass this by setting manually the PYTHON_EXECUTABLE variable.

@nim65s
Copy link
Contributor

nim65s commented Dec 4, 2023

I think you are right, and we should export this.

You can also bypass this with sudo apt install python-is-python3 , and/or sudo apt autoremove --purge \*python2\*. I'd recommend both :)

@nim65s
Copy link
Contributor

nim65s commented Dec 4, 2023

I took a look at https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/python.cmake#L58, and sadly it seems that the arguments to FIND_PYTHON() macros are not used at all, and the documentation is wrong about the ability to use eg. FIND_PYTHON(3.8 EXACT REQUIRED) in eigenpyConfig.cmake

@jmirabel
Copy link
Contributor Author

jmirabel commented Dec 4, 2023

If I'm not wrong I'm the one who wrote that. I'm 99% sure it did work when I wrote that.

@jmirabel
Copy link
Contributor Author

jmirabel commented Dec 4, 2023

After double checking, yes, it was using FIND_PACKAGE(PythonInterp ${ARGN}), which isn't the case anymore.

@nim65s
Copy link
Contributor

nim65s commented Dec 4, 2023

This is still in https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/python.cmake#L214, but only for CMake < 3.12, And we also enforce CMake >= 3.10.

@jcarpent
Copy link
Contributor

Still an issue @jmirabel?

@jmirabel
Copy link
Contributor Author

I don't think the issue has been resolved.

It would be cleaner to set the Python version in the export file but I would not mind if you prefer to close this. It is rather easy to bypass.

@nim65s a low effort solution would be to compare the Python version found with the exported compile-time Python version and just fail when they happen to be different.

@nim65s
Copy link
Contributor

nim65s commented Feb 12, 2024

I still think we should set this version in the FINDPYTHON() call in eigenpyConfig.cmake, and fix the argument use of this FINDPYTHON() macro. I could work on this, but probably not this week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants