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
WIP: Embedding Rust into a C++ CMake project #156
Conversation
E0658 means your compiler is too old. This project requires rustc 1.42.0 or newer. |
Ok, totally forgot about the compiler version. Should be working now (if changed to staticlib in Cargo.toml). Last non-cosmetic thing is that it's building only a static lib, not a shared one. Looks like a limitation of cc-rs. |
How would you like to proceed with this? Do you want to put together a Travis build to test with CMake in CI? We already test Bazel and Buck and Cargo so it would be an appropriate way to demonstrate how a CMake setup involving this crate is intended to work. |
If you want it in this repository then we can have it. Although it doesn't really depend directly on the cxx code of the repository, it should load everything from crates.io. About CMake: it has different generators. I can deal with "Unix Makefiles" generator on Linux, but I haven't planned to test others like Xcode, MSVC, ninja, etc. |
Do you want to maintain a separate repo as a sort of example project using CMake + CXX? We can add a link from the readme here. That keeps it isolated from unpublished changes in this repo and more representative of how a downstream project would use the two. |
Yes, I'll make it as a fork of the cmake-cargo repo. I've partially worked around the problem of the shared library. It happens because the glue code is compiled into a static library and then linked into a shared one without "--whole-archive" flag (the shared library itself doesn't need any symbols from it so it drops it). It can be probably worked around with options and env vars for cargo, but I did some relinking in CMake for now. Other part of the problem with shared libraries is that cargo doesn't like building rust parts into shared libraries, especially for cdylib. With dylib and The two actual FFI questions are:
|
I don't know anything about CMake, but based on your questions it sounds like it would be easier for you to follow the non-Cargo workflow instead (https://github.com/dtolnay/cxx/tree/0.3.0#non-cargo-setup). Both of those things are specific to how Cargo lays out its build directory. |
Thank you. When I read "Non-Cargo setup" I thought that the whole thing including rust code is to be built without cargo. FFI integrates fine. The only thing left is to convince cargo to build shared libraries for everything because currently every plugin of this demo (currently one) is getting a separate copy of the whole rust runtime. |
Hello @ChipmunkV! I have been experimenting with Cmake and Cxx but I have some issues testing and running your example. I am on a mac running clang so I removed the
I am a bit of a noob in Cmake so sorry if I am just missing something obvious. But I'd really appreciate any help if you have any ideas of why this fails? |
@Nehliin , run the build in verbose mode (make VERBOSE=1) to see what commands are executed. Copy-paste individual commands and run/debug them manually. Maybe CMake rearranges the arguments differently, maybe such usage of the linker arguments is too gcc specific.
|
@ChipmunkV Thanks for the tip! I finally managed to get it to work by simply expanding the example in the more updated cmake-cargo repo you linked in the original post. I modified it to use cxx instead. I had to remove all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll go ahead and close the PR at this point since it wasn't intended to get merged to begin with, but it'll be here for anyone searching for CMake guidance (https://github.com/dtolnay/cxx/search?q=cmake&type=issues). Thanks for figuring all of this out!
It's not a real PR, more like a question about the demo code in demo-cxx/ and demo-rs/.
The setup is an existing C++ CMake project, the goal is to be able to add Rust code to it. The C++ project is internally structured as a main application and shared libraries. In this demo we will have a main C++ application and a shared library. The shared library will be entirely in Rust except for the interface, the FFI will provide the C++ interface so the main application could link to it as to a regular C++ shared library.
I haven't found any main.cpp in the demo-cxx/ or demo-rs/, so there is probably a space for this kind of demo.
The first step is creating the demo-cmake/ dir, dumping the cmake-cargo into it, fixing workspace errors. Then testing their build:
The application of interest is demo-cmake/test/rust2cpp, it does the C-like variation of what we want. So the second step is adding parts of demo-cxx/ and demo-rs/ to that application (main.rs turns into lib.rs, demo.h turns into a pure-C++ interface for the library).
There are minor things such as: hardcoded include paths in demo.cc and build.rs, hardcoded cxx dependency path, cxxbridge complaining about the "target path" that has to end with "target" but instead ends with "out". I'm currently looking into this error that occurs while building the library:
So it doesn't compile yet. I suppose most of the work that is left is related to the Rust/cxx build system side.
Suggestions welcome. Maybe I've missed an obvious solution or maybe somebody has already done such an integration.