Bidirectional cxxbridge Issues
#280
Comments
|
I'm not too familiar with
Looking at your example, it seems this is because you do have a cycle in your headers. The rust bridge depends on the C++ header and the C++ header depends on the rust bridge. |
Hmm. It is possible to remove the bridge-include in the header, e.g.: But this didn't change anything though. Or am I misunderstanding your suggestion? |
Well, once you removed the cyclic depenency in the headers you would also have to adapt the CMake dependencies
You probably want to remove this line - I would expect you would want to link the rust bindings into a C++ library and not into the rust crate. |
|
Appologies for the slow replies, ended up being rather busy during the holidays, forgetting this thread. Anyways:
Removing that line does seem to work to fix the I guess there's something missing on the Rust side then to make these symbols (that are compiled on the CMake side) available? |
|
In which language was the final executable defined again? Rust or C++? |
|
The final executable in this case is a Rust binary called "texture_test", in case it's helpful, here's the full commandline as it is output by Although, looking at this it looks a little weird, I don't really see why the C++ compiler is invoked here |
|
In this case you might be missing a
It is quite common that the linker is not invoked directly, but via the compiler. Corrosion by default sets the linker to be the C++ compiler (if C++ is compiled) to ensure that the default C++ libraries are linked. On the most recent master there is a new option |
|
Ah, I just realized that this is probably where the circular dependency issue comes up. Could you checkout the |
|
Actually, it seems like limiting the dependencies to just the targets that need it seems to work, although one could argue that it is a bit of a workaround. That said, the build went a lot further this time, but fails when it tries to find the Which is interesting, and probably easy to fix: Does
Sure, I'll give that a branch a spin tomorrow when I got some more time! |
|
Yes, the header is placed under |
|
Seems like using the line
Hmm, odd. My paths are slightly different: There seems to be a second After hacking at it awhile, I the Rust side of the bridge to this: And forced the include directory This got me a tiny bit further. Does corrosion keep the Which I belive are the headers to the helper structs that |
Did this one not work? I think you would want to link the imageio-cxx crate into your final executable, not an intermediate library.
Yes, that seems to be intentional. I don't remember why though - I'd have to look into that. Probably simply to add a namespace to your includes, so you do `#include "cxx_target/blah.h" to make conflicts less likely.
AFAIK this extra utliity header does not exist when using the commandline |
|
I've added a simple test based on what you wrote, and it seems to be compiling now. One thing that I haven't figured out yet is how to get a non-absolute path working with the |
Oh, I think I misunderstood your previous comment: I figured you wanted me to try to use the line That said however, I must say that this feels like a bit of a band-aid rather than a proper fix. At least in my case, the
Makes perfect sense to me, just wanted to be sure :)
Ah, I see, I must have missed that note in the Have you seen any of these before?
That's interesting, I think I got that to work using the line: (The
This looks good to me at least, perhaps the include statement I mentioned above should be included? Or perhaps that should be done as a part of the On a separate note, I also noticed that the |
|
As I was unable to progress with the previous approach, I tried a different tack First, on the CMake side, I only import the crate and set the environment Annoyingly, I also need to remove all semicolons or translate them to something Further, in the Rust build script I then extract this information from However, while this works, I'm a bit concerned with the scalability of this |
Well, in CMake a list is just a semicolon delimited string, so you have to pay attention and quote the list variable basically each time you use it to prevent expansion. Possibly quoting the arguments to While working on #293 I did realize that the |
Hmm, that's probably another bug then, here's the behavior between quoting the variables vs not: Versus: It seems like the quotes become "part" of the first and last element somehow, not sure how that works. Here's the CMake changes from above, just in case:
Sure, I'll try to squeeze that in soon-ish |
Yeah, you need to quote the whole thing, otherwise CMake will keep the quotes.
|
|
Hmm, strange, that didn't actually change anything: Just for completeness I also tried to escape-quote the variable values: and to use single quote the internal ones: But this just gave the same result as before (inserting quotes in the first/last Either way, this is clearly a separate issue. Perhaps this should be lifted out |
In that case this is because of the
This can't be fixed - The user replacing the semicolon with another character is really the only solution then, AFAIU. Anyway, I did get something close to your example working, but since there are circular dependencies, this doesn't work with every linker. You may want to consider if you really need a circular dependency between the rust and the C++ libraries. Otherwise, linking with |
Apologies in advance if this is the wrong place to ask this, but anyway:
I have tried for a bit to use Corrosion to build and share code between a C++
project and a Rust project, starting with a simple example such as reading
images on the C++ side and sending the results back.
The CMake file is pretty straightforward:
The C++ bridge looks something like this:
and the Rust side of the same looks like this:
The build process works just fine, but any rust binary that attempts to use the
bridge triggers a linker error:
Some of the examples I found in the repository suggested that I should construct
the bridge on the CMake side (e.g., the
test/cxxbridge), so I tried to add thefollowing lines to the
CMakeLists.txt:This however seems to trigger dependency graph cycles in
CMake:So, I'm currently at a bit of loss, what is the recommended way for constructing
these kinds of bridges?
If nothing else, perhaps a slightly larger example with a bidirectional
cxxbridgeis warranted?The text was updated successfully, but these errors were encountered: