Rebuild pypy38 0 1 h3f84c1

[jorisv]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

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.

[traversaro]

@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).

[traversaro]

@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.

[jorisv]

@traversaro Thank for the tips, I will do the commit.

[jorisv]

@traversaro I've had some hard time to make it work.

• PyPy need the Python_SOABI suffix to load a C Extension.
• There is a bug in find_package(Python COMPONENTS Development Interpreter) that doesn't define Python_SOABI when CMAKE_CROSSCOMPILING is set.
• To bypass this, we can call find_package to the Development and Interpreter components separately.
  • In this case, the finder rely on python3-config but it keep finding the wrong one (BUILD_PREFIX or /opt/conda/bin)
  • When using PyPy, python3-config only exists in /opt/conda/bin
• Finally, I have set 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.

[traversaro]

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).

[traversaro]

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 .

[traversaro]

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.

[jorisv]

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.

[jorisv]

@traversaro All green ! :tada:

[traversaro]

Great, thanks a lot for the hard work!