Closed Jac-Zac closed 9 months ago
Yes, it's a problem still will SDKROOT. Incidentally, it's now fixed (for me anyway) in repo. I'm still having trouble with the wheels from the CI, though: even as it's build for Mac ARM, the binaries are the wrong architecture.
I kind of like the idea of having the CI build the wheels as the environment doesn't risk being polluted by any development setup I may have, but none of the wheels thus produced yet work on any platform (I still have to test the Windows' ones, maybe I get lucky). I'm wondering whether I should simply give up on that. :/
Ah, so the PyPI wheels are manually built? I feel your pain....
I always did so far, but then a CI recipe was contributed, so I thought that would be great. However, I'm finding the CI to be far more unwieldy than building manually. :(
The problem with Cling is that it will bake in the local build paths as an additional way to find things like include headers etc. I.e., when building and running on my own machines, the result is guaranteed to work more often when I test it locally than on any other, different setup. I.e. a clean, alternate, build environment that doesn't favor my own would be preferable to guarantee portability. But the github CI build runners are all over the place.
All that said, I really do hope that this particular issue itself is solved now that I patched cling to use xcrun
and changed the way it looks for sysroot
. :)
All that said, I really do hope that this particular issue itself is solved now that I patched cling to use
xcrun
and changed the way it looks forsysroot
. :)
Awesome, thanks so much! Let me know if there is a good way for me to test now, or I'll look forward to the next release.
Hopefully the run-time discovery (xcrun
, etc.) would help somewhat with CI builds. I can see that the multiple Xcode versions on GitHub runners could be a problem, for one thing. I'm sure there are other complications, though.
is that fix live? if not, please let us know when it is, can't wait to try it! we switched to pybind11 for one project, b/c of this issue, and ugh it was painful. would really love to stick with cppyy
@Alex-EEE: it's in the repo. I'm fighting the CI ... one other thing that would be great if that were functional, is that I could just point you to the artifacts to download.
I'm currently re-writing the workflow using the scikit-learn one as an example.
The CI path isn't going to work out: the ARM target is a cross-compilation, but the build process creates small helper executables. Presumably, it's possible to compile the latter for the host, while compiling the rest for ARM, but I'm giving up for now. The build process will be simplified once the move to Clang-REPL is complete.
For now, here's a wheel that should work, however. Appreciate feedback: http://cern.ch/wlav/cppyy_cling-6.28.6-py2.py3-none-macosx_11_0_arm64.whl
If confirmed, I can finally cut a new release...
(Edit just to say not to worry about pip complaining about version numbers when installing the above wheel. It's ABI compatible.)
Looks like this works for me!
With the latest cppyy installed normally from PyPI (showing failure case first, then the workaround, then the new cppyy-cling),
$ pip list
Package Version
------------- -------
cppyy 3.0.0
cppyy-backend 1.14.11
cppyy-cling 6.28.0
CPyCppyy 1.12.13
pip 23.3
setuptools 68.2.2
$ python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
ERROR in cling::CIFactory::createCI(): cannot extract standard library include paths!
Invoking:
LC_ALL=C /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -xc++ -E -v /dev/null 2>&1 | sed -n -e '/^.*include/,${' -e '/^ \/.*++/p' -e '}'
Results was:
With exit code 0
>>> ^D
$ SDKROOT=$(xcrun --show-sdk-path) python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
>>> ^D
$ pip install https://cern.ch/wlav/cppyy_cling-6.28.6-py2.py3-none-macosx_11_0_arm64.whl
Collecting cppyy-cling==6.28.6
Using cached https://cern.ch/wlav/cppyy_cling-6.28.6-py2.py3-none-macosx_11_0_arm64.whl (27.9 MB)
Installing collected packages: cppyy-cling
Attempting uninstall: cppyy-cling
Found existing installation: cppyy-cling 6.28.0
Uninstalling cppyy-cling-6.28.0:
Successfully uninstalled cppyy-cling-6.28.0
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
cppyy-backend 1.14.11 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
cpycppyy 1.12.13 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
cppyy 3.0.0 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
Successfully installed cppyy-cling-6.28.6
$ python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
(Re-)building pre-compiled headers (options: -O2); this may take a minute ...
>>>
I got the same result with xcode-select
pointing to either Xcode.app or CommandLineTools.
Should all be good now with release 3.1.0. Feel free to reopen if you find otherwise.
@wlav I have the same problem. Release 3 is not good for me because of a known issue of ns3 with it (#156, #175). Can you fix this on top of 2.4.2 and release a new patch for cppyy 2?
@wlav I have the same problem. Release 3 is not good for me because of a known issue of ns3 with it (#156, #175). Can you fix this on top of 2.4.2 and release a new patch for cppyy 2?
As the ns-3 maintainer for build/python/platform-specific stuff:
About 2, I built from master and still had the issue running first.py About 3, I think being able to debug inside an IDE is a feature we lose. Also, I suggest mentioning this in the installation documentation. I had to dig deep to come across these issues and find out what is the problem.
About 2, I built from master and still had the issue running first.py About 3, I think being able to debug inside an IDE is a feature we lose. Also, I suggest mentioning this in the installation documentation. I had to dig deep to come across these issues and find out what is the problem.
You can report these issues in https://groups.google.com/u/0/g/ns-3-users, or https://gitlab.com/nsnam/ns-3-dev/-/issues, not to pollute the cppyy tracker. The intended way for people that are not really sure what they are doing to consume the ns-3 bindings is via pip. :)
I'm on an M1 macbook and I was wondering if it works on apple silicon too. Because for some reason when I import cppyy I get this error:
I tried also installing Xcode but I still get an error. I also tried on another mac that wans't running apple silicon and it worked until I changed to a newer version of python that I installed with brew. Therefore I tried to run it on my mac on a virtual enviroment with the python that comes inlcuded which is Python 3.9.6 but it still didn't work. Maybe I'm missing something. If anyone needs other info I'll provide it. Thanks in advance