Open nbraud opened 1 month ago
I tried to work around the issue by running the cmake
build myself and copying libcppyy-backend.so
to python/cppyy_backend/lib
as the build instructions mentionned in the instructions.
However, even when doing so and bypassing my_cmake_build
, I run into a second issue: setup.py
attempts to run CMake's install
target... which does not exists.
I need to run setup.py
in order to build an installable wheel, as I'm attempting to package your software in nixpkgs.
@nbraud, are you sure you want to use our work-in-progress fork and not the main repository?
@nbraud, are you sure you want to use our work-in-progress fork and not the main repository?
I think so? At least the clang-repl
backend does not yet seem to exist upstream, unless I am mistaken.
PS: I already packaged (in my dev branch) CppInterOp and the patched LLVM version it needs, built to use the clang-repl
backend, though I've not yet been able to test them since I don't have a working cppyy/CPyCppyy packaged yet.
@nbraud, CppInterOp with the clang-repl backend should be fine to package. Why did you need patches of llvm for the clang-repl backend?
I am not sure if we want to package our fork of cppyy because it will cause confusion. @wlav, what do you think?
Your fork doesn't work, does it? Once it passes all tests, it should be fine, if properly versioned.
Your fork doesn't work, does it? Once it passes all tests, it should be fine, if properly versioned.
Yes, that fork works partially and that is why it is not merged upstream. Perhaps it is not the right thing to ship a package.
Why did you need patches of llvm for the clang-repl backend?
The build instructions for CppInterOp mentioned needing to apply patches from patches/llvm
. Is that not the case when using the clang-repl
backend and/or for recent-enough LLVM versions? I have to admit it would make things easier, packaging-wise.
I am not sure if we want to package our fork of cppyy because it will cause confusion. @wlav, what do you think?
To be fair, there was some amount of confusion going on, on our side, about which repo was the actively-developed one. Given what you said, I believe it makes more sense to package wlav's then, using the cling backend, and potentially switch over to the clang-repl
/CppInterOp backend once that's upstreamed. :+1:
Sorry for the confusion, and thanks a lot for clarifying what was going on there.
Why did you need patches of llvm for the clang-repl backend?
The build instructions for CppInterOp mentioned needing to apply patches from
patches/llvm
. Is that not the case when using theclang-repl
backend and/or for recent-enough LLVM versions? I have to admit it would make things easier, packaging-wise.
If you build it against llvm/clang-18 it should not need any patches.
setup.py
attempts to run a script namedcreate_src_directory.py
, which does not exist in the repository.