Closed jorisv closed 3 months ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@jorisv you probably need also -DPython3_EXECUTABLE=$PYTHON
and -DPython_INCLUDE_DIR:PATH=$PREFIX/include/$(ls $PREFIX/include | grep "python\|pypy")
(the trick is specifically to handle the corner case of aarch64/ppc64le cross-compilation with pypy).
@jorisv you probably need also
-DPython3_EXECUTABLE=$PYTHON
and-DPython_INCLUDE_DIR:PATH=$PREFIX/include/$(ls $PREFIX/include | grep "python\|pypy")
(the trick is specifically to handle the corner case of aarch64/ppc64le cross-compilation with pypy).
I can add it myself, but better coordinate otherwise the commit risk to be lost due to force pushes.
@traversaro Thank for the tips, I will do the commit.
@traversaro I've had some hard time to make it work.
Python_SOABI
suffix to load a C Extension.Python_SOABI
when CMAKE_CROSSCOMPILING
is set.find_package
to the Development and Interpreter components separately.
python3-config
but it keep finding the wrong one (BUILD_PREFIX
or /opt/conda/bin
)python3-config
only exists in /opt/conda/bin
CMAKE_CROSSCOMPILING
to OFF before calling the find_package(Python)
to use the Do you know this issue and if there is a nicer way to overcome this ?
Also, do you know why python3-config
doesn't exists with PyPy ?
Anyway, I succeeded to build on all platform. I will clean the git history and the PR could be merged.
Thanks a lot for the hard work @jorisv !
Do you know this issue and if there is a nicer way to overcome this ?
Actually not, I think this is exactly the issue I were I was finding in https://github.com/conda-forge/idyntree-feedstock/pull/48 and I was not able to debug, thanks for identifying the source of the problem. Reading https://gitlab.kitware.com/cmake/cmake/-/issues/25145, I guess the possible clean way to deal with this is just avoid to pass Interpreter
to find_package(Python ...)
if CMAKE_CROSSCOMPILING
is set, and just ask the users to pass PYTHON_EXECUTABLE
, DEF_PYTHON_PREFIX
or any variable for which the Python executable was required manually (cross-compiling build are tricky so I think it is typically ok to ask for users for more configuration).
A possible alternative solution is to just manually set externally Python_SOABI
?
Anyhow, I think there is no need to block the review in improvements on the CMake side (that it would be great to eventually upstream).
Also, do you know why
python3-config
doesn't exists with PyPy ?
Apparently upstream does not think it is useful and instead projects should use the sysconfig
Python module: https://github.com/pypy/pypy/issues/3202 .
There is a failure for pypy Windows builds:
(base) %SRC_DIR%>conda activate "%PREFIX%"
import: 'casadi'
import: 'casadi'
Traceback (most recent call last):
File "D:\bld\casadi_1717434651243\test_tmp\ipopt_nl.py", line 6, in <module>
x = SX.sym("x",2)
File "D:\bld\casadi_1717434651243\_test_env\lib\site-packages\casadi\casadi.py", line 6710, in sym
return _casadi.GenSX_sym(*args)
NotImplementedError: Wrong number or type of arguments for function 'GenSX_sym'.
Prototype:
sym(str,int,int)
You have: '(str,int)'
WARNING: Tests failed for casadi-3.6.5-py39h5e8379c_3.conda - moving package to D:\bld\broken
TESTS FAILED: casadi-3.6.5-py39h5e8379c_3.conda
##[error]Cmd.exe exited with code '1'.
Not a problem for me skipping those, but I am not sure what you need on the pinocchio side.
A possible alternative solution is to just manually set externally
Python_SOABI
?
I think I tried it and it didn't succeed. The python finder unset this variable manually at each call. Apparently, it's to be able to call multiple time find_package(Python)
to find different interpreter/libs (for cross compilation for example).
But we can set a custom variable (CASADI_Python_SOABI
) and set the Python_SOABI
with this value if it's empty.
There is a failure for pypy Windows builds
I already saw this issue for Linux PyPy. It should be easy to fix.
Apparently upstream does not think it is useful and instead projects should use the sysconfig Python module: https://github.com/pypy/pypy/issues/3202 .
I will maybe try to reopen this discussion since CMake finder can heavily rely on python3-config script.
@traversaro All green ! :tada:
Great, thanks a lot for the hard work!
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)